5 ms·

Eh, I don't really buy any of that. Have you actually worked in the mechanical engineering world? I feel like it's far more gray than software engineering. I mi

Eh, I don't really buy any of that. Have you actually worked in the mechanical engineering world? I feel like it's far more gray than software engineering. I might have a specs on the output, but the environment is the actual physical world with all of its problems. Corrosion, temperature, vibration, dirt, dust, etc. It just screws with you the entire time. The abstract environment of a computer is tame in comparison. The only thing you have to worry about is the dependencies - which is basically configuration managament. Configuration managament is a problem in the mechanical world too. Except if you design a power plant to Rev B of the drawing, and show up with a Rev A drawing part that doens't fit, you might be out millions of dollars and months of times because there is no 'recompile' button when it comes to giant machined parts. As for your specific examples, 'different kinds of hardware' is no different than saying my system needs to work at -30F and 130F temperature. Materials behave very differently at different temperatures and we have to account for that. Some metals are weaker in temperatures as high as +25F. That's something you will see all the time. You are also vastly over-rating the complexity of scaling. It's really not that hard. Are you really going to tell me it's harder to figure out how to scale a web site than it is to build a rocket engine? Because there are about 1,000 web sites out there with millions of users and only about 10 organizations building rockets.

haberman 14y ago
> Have you actually worked in the mechanical engineering world? No (which I admitted up-front). But have you ever worked on large, high-availability distributed systems? When you say that scaling is "really not that hard" I'm suspect that the answer is no. It is absurdly more complex than single-machine programming. There may be more people building large websites, but that probably has a lot to do with the fact that a lot more people visit websites than ride on rockets. If you look at the number of support staff needed to run a website like Amazon vs. launch a rocket, I bet they wouldn't be that far off. I'm not saying mechanical engineering is easy, I'm just saying the software isn't easy either. I also don't think that you can draw the conclusion that because we have 60 years of mechanical engineering process that software should fit into the same processes.
- Retric 14y ago
  Having worked on large scale systems I would agree with him. Scaling is only hard when you completely ignore it at the design phase. IMO, designing scalable systems is often easier, because they need to be loosely coupled to handle failures. Honestly, I think most of the hard real world software problem tend to deal with legacy systems and the near organic mess that builds up over time. So what's your database system like. Well, we are 1/2 though the transition between A and B, we don't have a DBA so Bob wrote something to create build scripts based on changes made in this file. It's buggy and we are starting to try out C but if you ...
  - haberman 14y ago
    > Honestly, I think most of the hard real world software problem tend to deal with legacy systems and the near organic mess that builds up over time. Have you read papers like: http://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf http://www.allthingsdistributed.com/files/amazon-dynamo-sosp... http://research.google.com/archive/bigtable-osdi06.pdf http://research.google.com/archive/bigtable-osdi06.pdf http://kowshik.github.com/JPregel/pregel_paper.pdf http://kowshik.github.com/JPregel/pregel_paper.pdf http://www.research.ibm.com/people/m/michael/ieeetpds-2004.pdf http://www.research.ibm.com/people/m/michael/ieeetpds-2004.p... These papers all describe solutions to "hard real world software problems" and have nothing to do with legacy systems. If you think there aren't hard problems in software, you're probably not working on one.

haberman 14y ago

> Have you actually worked in the mechanical engineering world? No (which I admitted up-front). But have you ever worked on large, high-availability distributed systems? When you say that scaling is "really not that hard" I'm suspect that the answer is no. It is absurdly more complex than single-machine programming. There may be more people building large websites, but that probably has a lot to do with the fact that a lot more people visit websites than ride on rockets. If you look at the number of support staff needed to run a website like Amazon vs. launch a rocket, I bet they wouldn't be that far off. I'm not saying mechanical engineering is easy, I'm just saying the software isn't easy either. I also don't think that you can draw the conclusion that because we have 60 years of mechanical engineering process that software should fit into the same processes.

Retric 14y ago
Having worked on large scale systems I would agree with him. Scaling is only hard when you completely ignore it at the design phase. IMO, designing scalable systems is often easier, because they need to be loosely coupled to handle failures. Honestly, I think most of the hard real world software problem tend to deal with legacy systems and the near organic mess that builds up over time. So what's your database system like. Well, we are 1/2 though the transition between A and B, we don't have a DBA so Bob wrote something to create build scripts based on changes made in this file. It's buggy and we are starting to try out C but if you ...
- haberman 14y ago
  > Honestly, I think most of the hard real world software problem tend to deal with legacy systems and the near organic mess that builds up over time. Have you read papers like: http://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf http://www.allthingsdistributed.com/files/amazon-dynamo-sosp... http://research.google.com/archive/bigtable-osdi06.pdf http://research.google.com/archive/bigtable-osdi06.pdf http://kowshik.github.com/JPregel/pregel_paper.pdf http://kowshik.github.com/JPregel/pregel_paper.pdf http://www.research.ibm.com/people/m/michael/ieeetpds-2004.pdf http://www.research.ibm.com/people/m/michael/ieeetpds-2004.p... These papers all describe solutions to "hard real world software problems" and have nothing to do with legacy systems. If you think there aren't hard problems in software, you're probably not working on one.