Hacker News new | comments | show | ask | jobs | submit login

If we treated programming like engineering we would finish one project every twenty years or so, and proceed to work on the next for the next twenty years.

There's simply no such counterpart in physical engineering to the iterative programming process. Engineers know how to build a bridge, that's why a particular design succeeds and is then followed by construction properly carried out. Programmers face unknown and unsolved problems all the time; in fact, a solved problem is not worth the programmer's time. A solved problem has already been implemented several times and can be reused, either literally or conceptually.

Engineers have been trying to solve the problem of a practical electric car with acceleration, velocity, range, and reload time comparable to petrol engines for decades. New things take time.

The reason we can write complex software in a few years instead of decades is that in software world, luckily, the cost of building, compiling, and trashing a prototype is negligible. Conversely, the complexity of projects has been upped a corresponding notch but only to the extent that we can still actually finish some projects.




Actually as someone with degrees and experience in both fields, you face unknowns FAR more often in the physical world than the software world. Man if only I had a step debugger and some logs for that turbine that just exploded.

There are a lot of reasons for the difference in disciplines but saying that software is "unknown and unsolved" is pretty far off the mark.


If what you say is true, we'd have electronic voting. Why don't we have that?

Physical engineers face unknowns all the time. Building in unknown environments for example. New materials. Climate change. I can't even count the number of different designs for bridges, buildings, and cranes.


Yes, but at least you know you're building a bridge. Instead of, say, developing a game and discovering your users want a photo sharing site instead (flickr). That's an extreme example, but it's very rare to build software that doesn't deviate significantly from what is initially specified. You could never engineer in those conditions.

And once you build your bridge, you're finished. It just has to stand there and take the load. It doesn't have to be unpredictably changed over the course of it's lifetime to also function as an airstrip and shopping mall.

Even the simplest of real-world software products you typically need to grow and adapt - sometimes dramatically - over time.


We DO have that- don't mistake America for the world.


"Engineers know how to build a bridge"

Even then it can still take them a few tries to get it right:

http://en.wikipedia.org/wiki/Millennium_Bridge_%28London%29


"There's simply no such counterpart in physical engineering to the iterative programming process."

Not true! There are so-called handbook engineering problems -- change the ratios in this gear box -- that can be solved by a monkey with a textbook.

However design-from-scratch hardware engineering usually involves a great deal of iteration. The first phase of designing a new chemical or fluid system is a mini-research project to measure the performance curves of various possibilities under a wide range of conditions, and if none of them are good enough it turns into a blue-sky science project. Radio electronics projects commonly start out as a pile of tiny two-layer circuit boards, one for each subsystem, so they can be cheaply iterated in parallel, instead of having to repeatedly redo a single massive board. ("We have to spin (redo) the system board" not being a happy phrase to a project lead.)

In all the sensor and detector projects I worked on, the embedded real-time firmware was always the bright spot that was practically guaranteed to work.

Don't even get me started about designing research hardware for scientists ...




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: