Software industry vs. the construction industry

Saw this on a Slashdot thread about how "software engineering" is not really engineering, and how if software emulated "real" engineering it would be better. This guy (girl) made the point that for construction, it's just as bad as for software.

Re: For the life of me (Score:5, Insightful)
by Linux Ate My Dog! (224079)on 2003.02.18 8:17 (#5326407)
(http://exonome.com/fj/)

Why not try to take a look at some of the long time methods used by engineering industries to see how they go about designing bridges and cars and stuff like?

I live in Boston, home of the Big Dig. Right now is not the best time to impress me with construction as a model for controllable effective on-time on-budget engineering of large-scale projects.

In fact, we get to hear this a lot as software engineers "Look at construction! They got it right!" Well, of all big construction projects I remember (Betuwe tunnels in the Netherlands, Stopera in Amsterdam, Big Dig in Boston) went into time and costs overruns, often by 100 to 400% on either variable.

And then there is my bathroom which I had remodeled a year ago, and the stories of my homeowner friends who did the same. On time? On budget? Don't make me laugh. Go do the rounds among people who have had remodeling done: horror story after horror story. Construction people were like software engineers in the dot-com boom: flooded with offers, so they would overbook and the customer who complained loudest would get his project done. Many sub-teams (projects, tilers) did and do not communicate, project leads are at the mercy of the scheduling of the sub-contractors, the quality is not standardized at all but incredibly variable so you have to get "lucky" with who has a slot free to do the work on your project, many of the people are overworked or "self-medicated" to deal with their stress and the conditions of labor.

I bought the whole "Look at construction!" mantra, and then I actually looked at how construction was done. These guys wing it as much as we do for the small projects, and when they can't wing it for the big ones, major shit happens like on our projects. And the old COBOL software is still running after 40 years and will keep running as long as the environment doesn't change, just like bridges stay up for decades as long as the environment doesn't radically change.

Do you think that GM people stand around and talk about Extreme Engineering for their engineers who design high tech engines?

Actually, yes, these people are constantly re-evaluating their process because their time-to-market requirements are constantly getting tighter and tighter. Just read Business Week for six months and follow the changes in the auto industry through their articles: they are all about faster, faster, and listen-to-the-customer constant process-reengineering, with CEO and design heads being hired and fired depending on how well they can make their human- and machine-assembly-lines line up and fire.

Software industry == tobacco industry?

"The thing that will really improve software is when someone figures out how to establish a [more] direct link between the risks of using a product and the creation of the product. The software industry seems to think the tobacco industry business model is a good one. It's okay to kill your customers, there will always be a new one to replace the one you just lost."

— Scott James, as seen in the 15 March 2002 issue of Crypto-Gram

It's not about lines of code

http://softwaredev.earthweb.com/sdtech/article/0,,12065_988641,00.html
By Charles Connell
Everyone wants programmers to be productive. Managers of programmers want maximum productivity — it gets the work done faster and makes the managers look good. All other things being equal, programmers like being productive. They can get home earlier, reduce stress during the workday, and feel better about their finished products. Programming productivity is even in each country's national interest, since it advances the country's position in the worldwide software industry.

Unfortunately, the standard definitions of software productivity are incorrect. They miss the essence of software development. This article examines some of the usual definitions for programmer productivity, shows why they are wrong, and then proposes an alternate definition that accurately captures what programming is really about.

Continue reading "It's not about lines of code"

Real programmers write in…

A recent article devoted to the macho side of programming made the bald and unvarnished statement:

Real Programmers write in FORTRAN.

Maybe they do now,
in this decadent era of
Lite beer, hand calculators, and "user-friendly" software
but back in the Good Old Days,
when the term "software" sounded funny
and Real Computers were made out of drums and vacuum tubes,
Real Programmers wrote in machine code.
Not FORTRAN. Not RATFOR. Not, even, assembly language.
Machine Code.
Raw, unadorned, inscrutable hexadecimal numbers.
Directly.

Lest a whole new generation of programmers
grow up in ignorance of this glorious past,
I feel duty-bound to describe,
as best I can through the generation gap,
how a Real Programmer wrote code.
I'll call him Mel,
because that was his name.

Continue reading "Real programmers write in…"

Raining instructions

Some people distinguish between biological life and machines. But if you look deeply enough, biological life is just a machine called DNA. Richard Dawkins said it best in chapter 5 of his book The Blind Watchmaker, after observing downy seeds falling from a willow in his garden:

It is raining instructions out there; it's raining programs; it's raining tree-growing, fluff-spreading, algorithms. That is not a metaphor, it is the plain truth. It couldn't be any plainer if it were raining floppy discs.