5 ms·

Exactly - this article makes the very common (still) (1) mistake of thinking construction of software == writing code. Construction of software is compiler/inte

Exactly - this article makes the very common (still) (1) mistake of thinking construction of software == writing code. Construction of software is compiler/interpreter/all the machinery that kicks in to take some text or instructions and makes it do something. To correct the analogy with building physical things - you could compare the architect designing a bridge (and arguing with engineers about materials and budgets) with writing code - that would be a fair comparison. The construction of software has been automated for some time. This works just fine for construction of physical things because the cost sunk into to the "non construction" bit is tiny compared to the whole project - so no one spends too much time thinking about methodologies and automation of an architect coming up with the concept of a building. (1) I note in the article the person mention spent time as a consultant in a big consulting company - this view is still held by them at least with the last brush I had with organisations like that (and they are incredibly frustrated by it).

andrewem 14y ago
The excellent book "Dreaming in Code" (1) follows a software project that takes way longer than expected, keeps changing goals, and is generally a mess. The author says "If the subject of software’s flaws is discussed for more than a few minutes at a time, it is a certainty that someone will eventually pound a fist on the table and say, “Why can’t we build software the way we build bridges?”". Then he shows how the San Francisco Bay Bridge project ended up going very much like a software project, complete with major changes in specs years into building. And of course, since I'm in Boston I'm required to mention the Big Dig (2), which was a tunnel and bridge project that cost over $14 billion. Oh, and a ceiling panel fell, killing a woman in her car. And the guardrails in the tunnels tend to kill motorcyclists who would otherwise suffer only minor injuries. Plus the all 25,000 of the 120 pound (55 kg) light fixtures in the tunnel ceilings have to be replaced lest more of them fall, maybe killing more people. But yeah, let's keep trying to make software engineering just like civil engineering. 1. http://www.dreamingincode.com/ http://www.dreamingincode.com/ 2. http://en.wikipedia.org/wiki/Big_Dig http://en.wikipedia.org/wiki/Big_Dig
drpancake 14y ago
Or alternatively you could say writing assembler is the software equivalent of building physical things by putting together individual molecules. Physical builders work at a higher level of abstraction too. I think the analogy is becoming a little stretched though.
- robryan 14y ago
  In the plumbing example in the article, the plumber isn't first making pipes from raw materials. They get them pre built in standardized lengths, diameters, thicknesses and materials. Same can be said for the compiler providing a standard, generally agreed upon abstraction.
  - bgilroy26 14y ago
    Wow, the pipe-building factory (generating standardized parts to be assembled by the plumber) to compiler building (generating standardized machine code to be assembled by the high level language programmer) comparison is really cool! I feel like the ISO/ANSI etc standards-making bodies are where the analogy breaks into time and space.
arethuza 14y ago
The idea that code is the design and it's the compiler doing the construction has been around for quite a long time: http://www.developerdotstar.com/mag/articles/reeves_design_main.html http://www.developerdotstar.com/mag/articles/reeves_design_m...
- michaelneale 14y ago
  Thanks - yes I thought it was an old idea (might even be older - but I can't find anything).
bigiain 14y ago
" … construction of software == writing code … " In one sense there _is_ this part of "constructing software", and _largely_ it can be done by the software equivalent of stereotypical "construction workers". (This is what a lot of people who've tried outsourcing to India are trying to do.) The problem is, while you can collect a pickup full of Mexicans who can lay bricks / hang sheet rock / tar roofs on most street corners in the south of The Mission, and they'll do a great job of it if you give them good directions - you don't expect those guys to be making architectural or structural decisions, or zoning or permitting or code decisions. "Code writers" have to make those sorts of decisions every day - a current high-profile example is Marius Milner and "his" decision about what data Netstumbler should collect from the Streetview cars. One of the biggest software companies ever, having ethical/legal/policy decisions made by the coder-on-the-spot (at least if you believe Google's representations on the topic). Or Apple with Lion debug-logging clear text passwords for FileVault, and having it escape "into the wild". The "architect" and the "civil engineer" and the "structural engineer" who have important roles in the world of building physical things, the guys who sign off on bridges or tunnels or even just-repaired airliners, the guys who put their careers on the line when they sign the paperwork, the guys with qualifications and certifications and often indemnity insurance to satisfy society that they understand the risks - for the vast majority of software/websites discussed here that's reasonably likely to be a 22year old college dropout aiming to be "the next Zuck". Even in small and medium enterprise sized businesses, those roles are largely thrust upon whichever developer seems to be good (and doesn't duck their head quickly enough). And if the shit hits the fan, they say "sorry boss, it seemed like the right answer at the time" (and hopefully doesn't get hung out in the press like it seems Milner has been…) (And the "big consulting companies" mentioned in the post I'm responding too, in my limited experience they often seem to want to make all the architectural/engineering/policy/ethical/legal decisions, then leave with their paycheck before the "codemonkeys" implement it all, and not be contactable when their "solutions" turn out to be incomplete/contradictory/impossible) I _hope_ government regulation of "software construction" isn't the answer (at least not for software that'll just cost investors money when it fails, as opposed to bridges or airliners that'll kill people), but I think lines of responsibility and authority need to be more explicitly identified in many software projects, with appropriate authority conferred on the people burdened with the responsibility. Holding developers to deadlines without giving them the authority to adjudicate on them or be involved in the determination of them, is a startlingly common way to have your developers cut corners - and worse, feel entirely justified in cutting corners and convincing themselves they're "doing the right thing".

andrewem 14y ago

The excellent book "Dreaming in Code" (1) follows a software project that takes way longer than expected, keeps changing goals, and is generally a mess. The author says "If the subject of software’s flaws is discussed for more than a few minutes at a time, it is a certainty that someone will eventually pound a fist on the table and say, “Why can’t we build software the way we build bridges?”". Then he shows how the San Francisco Bay Bridge project ended up going very much like a software project, complete with major changes in specs years into building. And of course, since I'm in Boston I'm required to mention the Big Dig (2), which was a tunnel and bridge project that cost over $14 billion. Oh, and a ceiling panel fell, killing a woman in her car. And the guardrails in the tunnels tend to kill motorcyclists who would otherwise suffer only minor injuries. Plus the all 25,000 of the 120 pound (55 kg) light fixtures in the tunnel ceilings have to be replaced lest more of them fall, maybe killing more people. But yeah, let's keep trying to make software engineering just like civil engineering. 1. http://www.dreamingincode.com/ http://www.dreamingincode.com/ 2. http://en.wikipedia.org/wiki/Big_Dig http://en.wikipedia.org/wiki/Big_Dig

drpancake 14y ago

Or alternatively you could say writing assembler is the software equivalent of building physical things by putting together individual molecules. Physical builders work at a higher level of abstraction too. I think the analogy is becoming a little stretched though.

robryan 14y ago
In the plumbing example in the article, the plumber isn't first making pipes from raw materials. They get them pre built in standardized lengths, diameters, thicknesses and materials. Same can be said for the compiler providing a standard, generally agreed upon abstraction.
- bgilroy26 14y ago
  Wow, the pipe-building factory (generating standardized parts to be assembled by the plumber) to compiler building (generating standardized machine code to be assembled by the high level language programmer) comparison is really cool! I feel like the ISO/ANSI etc standards-making bodies are where the analogy breaks into time and space.

arethuza 14y ago

The idea that code is the design and it's the compiler doing the construction has been around for quite a long time: http://www.developerdotstar.com/mag/articles/reeves_design_main.html http://www.developerdotstar.com/mag/articles/reeves_design_m...

michaelneale 14y ago
Thanks - yes I thought it was an old idea (might even be older - but I can't find anything).

bigiain 14y ago

" … construction of software == writing code … " In one sense there _is_ this part of "constructing software", and _largely_ it can be done by the software equivalent of stereotypical "construction workers". (This is what a lot of people who've tried outsourcing to India are trying to do.) The problem is, while you can collect a pickup full of Mexicans who can lay bricks / hang sheet rock / tar roofs on most street corners in the south of The Mission, and they'll do a great job of it if you give them good directions - you don't expect those guys to be making architectural or structural decisions, or zoning or permitting or code decisions. "Code writers" have to make those sorts of decisions every day - a current high-profile example is Marius Milner and "his" decision about what data Netstumbler should collect from the Streetview cars. One of the biggest software companies ever, having ethical/legal/policy decisions made by the coder-on-the-spot (at least if you believe Google's representations on the topic). Or Apple with Lion debug-logging clear text passwords for FileVault, and having it escape "into the wild". The "architect" and the "civil engineer" and the "structural engineer" who have important roles in the world of building physical things, the guys who sign off on bridges or tunnels or even just-repaired airliners, the guys who put their careers on the line when they sign the paperwork, the guys with qualifications and certifications and often indemnity insurance to satisfy society that they understand the risks - for the vast majority of software/websites discussed here that's reasonably likely to be a 22year old college dropout aiming to be "the next Zuck". Even in small and medium enterprise sized businesses, those roles are largely thrust upon whichever developer seems to be good (and doesn't duck their head quickly enough). And if the shit hits the fan, they say "sorry boss, it seemed like the right answer at the time" (and hopefully doesn't get hung out in the press like it seems Milner has been…) (And the "big consulting companies" mentioned in the post I'm responding too, in my limited experience they often seem to want to make all the architectural/engineering/policy/ethical/legal decisions, then leave with their paycheck before the "codemonkeys" implement it all, and not be contactable when their "solutions" turn out to be incomplete/contradictory/impossible) I _hope_ government regulation of "software construction" isn't the answer (at least not for software that'll just cost investors money when it fails, as opposed to bridges or airliners that'll kill people), but I think lines of responsibility and authority need to be more explicitly identified in many software projects, with appropriate authority conferred on the people burdened with the responsibility. Holding developers to deadlines without giving them the authority to adjudicate on them or be involved in the determination of them, is a startlingly common way to have your developers cut corners - and worse, feel entirely justified in cutting corners and convincing themselves they're "doing the right thing".