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

I think the difference is that software is engineering that isn't treated like engineering. For example, if a new bridge is going to be built, years and years are spent building models, testing winds, and understanding the geography of the location. Models are tested in wind tunnels. Dampers are added for earthquakes that may or may not occur. Every truckload of concrete is tested. Metals are designed for exact specifications.

When software is built, the first prototype becomes the production version. People don't think about the future. Algorithms aren't chosen they are hacked together by someone who may or may not understand the system from beginning to end.

The problem with software, most times, is precisely that it is not treated as engineering. We build software to be thrown away. We don't build it to last. This article from Dan Bricklin changed my perspective on software.


He argues that we should treat software more like engineering projects and design and build it to last.

Furthermore, we require civil engineers building bridges to have degrees in civil engineering. For software, anyone can create it. People who never went to college even. But you'd never allow someone with only a history degree to design a skyscraper. We've become accustomed to software written by people who are not engineers. We don't spend the same kind of money on it and the users of it don't really care, because unlike a bridge, their lives don't depend on it not crashing.

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:


"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 ...

"We should treat software more like engineering projects and design and build it to last."

No, we shouldn't. If you build a bridge to last 200 years, it will remain unchanged for 200 years.

What piece of software can you possibly imagine still be useful if it remains unchanged for 200 years? 50? 10? Hell, can you name a piece of software that was last updated 5 years ago that you still find useful?

Most software becomes obsolete by the changing digital landscape within a year or two if it isn't updated to keep up with the times. That's a major difference compared to physical objects - the physical landscape doesn't change nearly as frequently. That said, we still don't build most physical objects to last 200 years except for the very largest of a projects - and we frequently demo small buidings to put up high rises as the city landscape changes.

Hell, can you name a piece of software that was last updated 5 years ago that you still find useful?

Yes, tons. For example, the firmware for my car's electronic fuel injection (EFI). A lot of software can't easily be updated, or lasts far longer than originally intended.

Treating software development as solely an engineering discipline is, in my opinion, a mistake. That being said, the vast majority of software projects today would benefit greatly from that approach.

Why was this downvoted?

Because of your obvious lack of knowledge about "real world" engineering. Think of the planning that goes into just simply replacing the guardrail on a bridge. How are you going to cut it off, replace it, and install a new one on a changing bridge while least affecting traffic? In the case of the bridge I drive over every day the answer was to remove each ~100'x100' section of road deck (there is one in each direction) and replace it in its entirety, one a night, for months. This was to widen the 5 lane bridge by about 3' and raise the guardrail by about a foot. Sure a "minor" revision but I guarantee you could have paid for Flickr and a pile of VC backed startups making a hundred different projects for the cost of having a crews of guys working for months, a barge crane, and thousands of tons of steel and concrete. It just isn't even comparable. Specs changing are a constant fact of life in real world engineering too, they just aren't the #1 issue that has to be dealt with.

I think you're illustrating my point perfectly. An absolutely minor change to replace a guardrail is more expensive "than Flickr and a pile of VC backed startups making a hundred different projects".

Engineering projects do not change frequently and radically. They can't afford to - but more importantly - they don't need to, certainly not at anywhere the pace of software.

A bridge may undergo some changes and facelifts over a 200-year period, but it's still basically the same bridge. But there isn't much software that could last even a fraction that long and not be completely obsolete (without most of it's code getting replaced). In the case of a bridge, the underlying geography isn't going anywhere. That's just not the case with software - even if the platform still exists, the rapid pace of technology means that the software will stop being of any practical use.

A piece of software needs to keep evolving, or it's dead. The same just isn't true of most 200-year engineering projects.

I've waxed eloquent about this on HN before, but some subfields of software development is rather treated like engineering (and, I would dare say, qualifies as engineering).

I work on avionics software. There is a lot of planning. There are formal requirements based on industry standards and the needs of the users. There are oodles of verification procedures to ensure that the software written does what the requirements demand. There are peer reviews. There is certification paperwork. There are quality audits on the requirements, the code, the verification, the reviews, and the certification paperwork. There are on-ground tests. There are flight tests.

We do require the "engineers" to have relevant degrees, and if our software crashes... well, hopefully nobody dies, but, it's a real and sobering possibility.

On the other hand, all of the engineering-esque work that goes into avionics would likely be utterly wasted on most web applications, iPhone programs, and video games.

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