You are Not a Software Engineer | Hacker News Reader

You are Not a Software Engineer

chrisaitchison.com

16 pointscmaitchison9 comments

The article likens the building of a skyscraper to the design of software. I think that the analogy here may be wrong (having made the same incorrect analogy myself).

Perhaps the correct analogy is that the building of a skyscraper is akin to copying software (i.e., building a new replica of a design). In this regard software is the ultimate engineering. Once you have the blueprint (the final source code), stamping out copies is perfectly reproducible. The program applies to many more environments than a skyscraper design.

On the other hand, designing a skyscraper is alot like writing software. The designer doesn't know what the building will look like. There is an iterative process where ideas are thrown around, design errors identified and fixed, etc.

In terms of quality measurements, the same measurements don't apply to software since each copy is a perfect replica. There is little need to measure how closely a copy reproduces the design, it is often perfect. The design may have flaws, but so may a building design.

Having said this though, it sure seems that software is alot more unreliable than most bridges and buildings, so the question is, "Why?"

I would liken software creation to something more like plumbing, cobbled together and constantly requiring maintenance.

Having said this though, it sure seems that software is alot more unreliable than most bridges and buildings, so the question is, "Why?"

I'd say it is that way because for many use-cases, the point where software becomes useful is much lower than it is for bridges. If my MP3 software has a bug, worst case is I have to use a different one and import my library. If my stereo has a problem, it could electrocute me.

    Having said this though, it sure seems that software is alot more unreliable than most bridges and buildings, so the question is, "Why?"

That's a good question. Off-hand, I would say that part of the reason has to do with experience. Humans have been constructing bridges and buildings for thousands of years. As such, engineering of this sort is generally well understood. Occasionally, when working with new materials or grander scales, past experience fails, e.g. Tacoma Narrows Bridge.

There is another important way that designing software differs from designing structures. Whether a building stands or collapses is governed by the laws of physics. On the other hand, software design takes place in an entirely abstract world, where the laws that govern it are sometimes subject to change. That combined with the sheer scale of much software makes it difficulty to thoroughly reason about it.

I'm done with these analogies. I find it a lot easier to make good decisions by asking direct questions about the situation I'm in and the outcomes I want.

edit: snark removal

The last line is a little presumptive for my taste. How do you know I didn't write the firmware for your pacemaker? There's gardened software and there's engineered software and both have their place.

Software is a lot more unreliable than bridges and buildings because it can be. People pay a lot of money to have reliable physical constructions. Some also pay for reliable virtual constructions (think 30-year-old space probes). There's no sensible business need for Facebook, say, to have three 9's reliability.

http://en.wikipedia.org/wiki/Reframing It's not that clever.

The problem with calling ourselves "software gardeners" is that gardeners do not earn as much money as engineers.

Reply on news.ycombinator.com