The Joel on Software Discussion Group (CLOSED)

A place to discuss Joel on Software. Now closed.

This community works best when people use their real names. Please register for a free account.

Other Groups:
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
TechInterview.org
CityDesk
FogBugz
Fog Creek Copilot


The Old Forum


Your hosts:
Albert D. Kallal
Li-Fan Chen
Stephen Jones

Classic mistakes in Software Development

This was posted on reddit:

http://www.stevemcconnell.com.nyud.net/rdenum.htm

I found it interesting as I have run into many of these mistakes myself. It still amazes me that Software Development has been around a good few decades now and yet no one seems to learn from the mistakes of the past.

Do other professions (e.g. construction) approach projects in such a haphazard way? When a bridge needs building do project managers insist that no design is done and people just get on with building the damn bridge?

I wonder if the problem lies more with management ineptitude or developers that don't take a firm stand and say 'no' to stuff, refusing to do things that just make a mockery of Software Engineering principles.
Robin Send private email
Saturday, April 11, 2009
 
 
The problem with comparing software and many other disciplines is software really is _soft_.  You can throw it all out and start over in an instant, and all you've lost is time, as opposed to raw materials, tear-down and cleanup time and effort, etc.
Doug Send private email
Saturday, April 11, 2009
 
 
And just so I'm not misunderstood, architecture, design and thinking ahead are still good ideas, even in _soft_ware. 

Well, for everyone else except for me! >:)
Doug Send private email
Saturday, April 11, 2009
 
 
I think part of it is that software is a rapidly changing technology, designed to support changing business processes.  So, its hard for the "right" way to ever be established.

Something like bridges on the other hand is very constant.  A bridge design from the Romans may still work even today.  And the goals I would expect don't change as much during the project.  It's still "suspend a road over the river and don't fall down".  I'm sure a bridge designer may explain its more complicated than that, but I think the point of software changing very rapidly compared to construction is still true.
Ryan Wilson Send private email
Saturday, April 11, 2009
 
 
our field will become a professional field the day people who read 2 or 3 books on programming will stop calling themselves professional programmers.
Victor the Python Artist Send private email
Saturday, April 11, 2009
 
 
Try hiring a contractor to do a remodeling job to an existing, "legacy" structure.  My home, built in 1871, predates electrical wiring.

I had a contractor put in a bathroom upstairs; it was something like 15% over the original spec in price (thanks to "change orders") and over 200% late.

If he could have found a way to bill me time and materials it would have been more like 100% over the original price.

It's not that software development sucks; it's that we, as an industry, seem interested in comparing our worst projects to the best, most repeatable work of other industries.  GM, for example, can predict the exact cost of a car down to a penny; to do that they had to make a million of the exact same car.  EVERY software project is different; we have no past history in the manufacturing sense.  (Companies that make money trying to make very very similar changes to standard software often fail in the marketplace, because someone else will write some LISP or something to allow the customer to make those customizations.  Perhaps the best example of this is Paul Graham and ViaWeb.)

Comparing a one-off software project to a car is a bad analogy.  It would be more apt to compare the cost of burning a CD or transferring some technology - which, it turns out, we can predict pretty accurately.
Matthew Heusser Send private email
Saturday, April 11, 2009
 
 
"You can throw it all out and start over in an instant, and all you've lost is time, as opposed to raw materials, tear-down and cleanup time and effort, etc."

You might have lost a shit load of money as well.
John Topley Send private email
Saturday, April 11, 2009
 
 
"You can throw it all out and start over in an instant, and all you've lost is time, as opposed to raw materials, tear-down and cleanup time and effort, etc."


The customer that depended on your software might have a different viewpoint.
Michael Rainey Send private email
Saturday, April 11, 2009
 
 
Of course this happens in other industries: it happens everywhere a project isn't managed properly.

Watch "Mr. Blandings Builds his Dream House" for a few excellent examples. Pay special attention to what happens when Mrs. Blandings asks to have the little room in the back turned into a potting shed so she could work with her plants(*). Sure, it's a work of fiction, but it's pretty damn close to what happens in the real world.

*
For those with better things to do than watch the movie (it's a nice rainy day movie BTW):  she " ...just asked to have a few of the left over flagstones put on the floor and a sink added." IIRC, that resulted in the contractor having to beef up the floor joists to take the weight of the stones, probably waterproof the subfloor before adding the stones, grout the flagstones, rip down a wall to run plumbing to a point that plumbing was never intended to go, etc.. resulting in a bill that sent Mr. Blandings through the roof.
farmboy Send private email
Saturday, April 11, 2009
 
 
Enumerations like this are not uncommon and reflect two basic principles:
 a. Software is not engineering - you can read the rest in my post:
http://design-to-last.com/Technical/software-development-is-it-engineering.html
 b. people like to categorize for "easier" management. unforatunately, the details matter and each problem is rooted in the specific details.
Daniel Leiderman Send private email
Saturday, April 11, 2009
 
 
"Do other professions (e.g. construction) approach projects in such a haphazard way?"

My spouse is a litgation lawyer specialising in construction cases - construction law is so specialised that (at least here in the UK) there are special legal processes that apply just to it.

Given the amount of construction related cases and the *relative* lack of software related litigation I would suggest that perhaps the software world isn't so bad after all. Perhaps for no other reason than our mistakes are made out of thousands of tons of concrete and steel!
Arethuza Send private email
Saturday, April 11, 2009
 
 
> You might have lost a shit load of money as well.

>The customer that depended on your software might have a
>different viewpoint.

I agree completely.  I'm just pointing out that starting over is clicking a button (deleting files), compared to razing a half-built building, hauling off the rubble, etc -- just reseting to a clean slate could be as big a job in construction as the original construction job.

In _both_ cases (software and construction) being late and over budget (and losing the money that might have been generated) is a bad thing.
Doug Send private email
Saturday, April 11, 2009
 
 
Let's be realistic - we can keep pointing out what's wrong but nothing's going to change.  There aren't enough quality managers, quality analysts and quality programmers to run every development project perfectly.

To go back to the bridge building analogy, if we needed to build ten thousand bridges in every city and we need to tear them down and rebuild them every ten years, you'll have failed bridge projects all over the place.
JoeP Send private email
Saturday, April 11, 2009
 
 
He's all over the place.

The only things not blamed are the makers of Charmin Ultra for not making it soft enough, and the escort service for not prorating their hourly rate into 5 minute blocks.
savagecat Send private email
Saturday, April 11, 2009
 
 
According to Santayana, those who do not learn from history are condemned to repeat it.

There's very little room in today's CS curriculum for a course on the history of software development.  Nevertheless, there are some things that are invariants over progress.  These things could be summarized in such a way that practicioners and especially managers could benefit from what has been learned by past mistakes.

The technology is constantly changing and the challenges have trouble keeping up with Moore's law.  I'll even allow that human culture has been profoundly altered by the age of information.  But human psychology is essentially identical to what it was in 1971, when Gerald Weinberg wrote [i]The Psychology of Computer Programming.[/i]

Weinberg's work is not the last word on the subject,  but it's got enough in it that is still true so that it shouldn't go on the scrap heap either.  And the cost of errors is high in SWE, even if erasing your errors is easy.

To briefly compare with civil engineering,  there's never been another Tacoma Narrows bridge mistake,  AFAIK.  If civil engineers treated their past with the same contempt that software engineers do,  there would have been several repetitions.
Walter Mitty Send private email
Sunday, April 12, 2009
 
 
The Tacoma Narrows comment pretty much strikes to the heart of the problem. We have known for a very long time how to manage software projects, but we just don't do it most of the time. Why not? There's not enough perceived at stake.

Nothing makes people learn from their mistakes like death. If you look at the areas where software is expected to be engineered, as opposed to just thrown together, the result of failure is often loss of life or injury. Civil engineers aren't special because they learned from their mistakes: they were essentially forced to do so because mistakes can kill. When they didn't step in fast enough, lawsuits and legislation did.

I can't put up a building with a floorplan greater than 12'x10' without a permit and inspections. That's because in the past people did, and either killed other people due to weak structure/poor design, or caused the next owner of the building to lose money.

The same kind of regulation is inevitable for software: you can do whatever you want up to a certain limit. Once you cross that limit, there will be formalized steps to take and procedures to follow. And all the whining about "it changes to fast.. blah, blah, blah" won't matter.

I'm placing bets on financial software being next to be regulated more closely.
farmboy Send private email
Sunday, April 12, 2009
 
 
The Tacoma Narrows comment pretty much strikes to the heart

>>I'm placing bets on financial software being next to be regulated more closely.

For that to happen won't there first need to be some sort of catalyst, financial software's own Tacoma Narrows?

With software increasingly being outsourced to cheap overseas workers, maybe one day a really important piece of software will be outsourced and go bad with disastrous financial consequences. This could be a catalyst.

Saying that, in the UK there was a very high profile and expensive piece of software that went wrong. It was a National Health service application for letting junior doctors apply for jobs: http://www.dailymail.co.uk/news/article-455070/Hewitt-abandons-hated-doctors-online-application-system.html . As well as not performing as the end users hoped it would, there was also a security flaw which allowed anyone to see a doctor's confidential details (you just had to know their id in the system and go the the correct url with that ID as a GET param). Despite this software regulation hasn't increased. I suppose, as a previous poster said, it's because no one actually died / got injured as a result.
Robin Send private email
Sunday, April 12, 2009
 
 
The Tacoma Narrows disaster cost the life of one dog and no humans.  By contrast the St. Paul interstate bridge disaster cost a lot in human life.  The engineers learned what needed to be learned in Tacoma Narrows, unless I'm wrong about there being repetitions.  It remains to be seen whether we've learned the necessary lesson from the St. Paul disaster.  There are literally hundreds of interstate bridges in various states fo disrepair.

Let's take an example where the necessary learning did not occur:  Hurricane Ivan.  The year before hurricane Katrina dealt New Orleans a glancing blow,  hurricane Ivan threatened to come ashore making a direct hit on that city. 

The experts predicted what would happen if Ivan hit New Orleans.  Their predictions were almost exactly right, judging by what Katrina ended up doing.  At the least minute,  Ivan turned and went over the Florida panhandle.  Everyone breathed a sigh of relief.  Then they went back to the status quo ante, being unprepared for the eventual hit.

How about the Challenger disaster?  The engineers were worried about two things:  the O rings,  and a launch at below a certain temperature.  They voiced the opinion that a launch was too risky.  But some people in the rocket company were told that they might lose the contract if their booster was a reason to scrub yet another launch.  so they got the engineers to change thier professional estimate.  The original estimate was right,  and seven lives were lost.

We're still trying to figure out exactly what went wrong with the Titanic.  But when the sister ship was built, at least there were plenty of lifeboats. 

When Al Qaeda bombed two US embassies in Africa, and then the USS Kohl,  the country didn't learn enough to prevent the Sept. 11 disaster. 

When the Comet jetliner went into production,  we didn't know enough about pressurized airplanes and metal fatigue.  It took aobut 3 crashes to make us learn.  We've alo learned the meta lesson for this disaster:  we now require all airliners to carry two flight recorders, one for data and one for voice.  This doesn't do an airliner any good,  but it sure helps problems from recurring.

One problem that we haven't learned however, is this:  why don't we have webcams at the end of every commercial runway,  and record every single landing?  We get enough bad landings so that getting those visuals would often tell us what's gone wrong.  You don't have to keep the uneventful landings.
Walter Mitty Send private email
Sunday, April 12, 2009
 
 
And actually, software is pervasive enough in today's society that people do occasionally die when it fails.  There have been books written about such "case studies".  One example that springs to mind is a radiation machine used as cancer treatment in hospitals.  There was a documented case where the machine's software had a bug that caused it to administer a lethal dose of radiation when the technician set it for a proper dose.  Colleges need to make a mandatory class that studies these kinds of worst case, real-life scenarios.
carrie cobo1 Send private email
Monday, April 13, 2009
 
 
carrie:
Software used in medical devices is already regulated. Nancy Leveson was an investigator in the Therac-25 incident and has a good book, "Safeware" about the need for regulation of software in critical industries.

The "problem"really isn't that we don't know how to write software, or that knowledge isn't taught (many courses in Software Engineering exist), but rather that it isn't *practiced* as widely as it should be.
farmboy Send private email
Monday, April 13, 2009
 
 
Software Engineering can be overkill for a small project.  Unfortunately, small projects can grow over time and never get engineered.

Sincerely,

Gene Wirchenko
Gene Wirchenko Send private email
Monday, April 13, 2009
 
 
" There's very little room in today's CS curriculum for a course on the history of software development. "

That's true Walter, I recall back in the 70s it was covered in one lecture. We just had less history then.
SumoRunner Send private email
Monday, April 13, 2009
 
 
Matthew Heuser has some points, but I slightly disagree.

I do think there has been enough projects, whereby we can reproduce. True, there are outliers and things that haven't been done. But, there has been plenty of CRUD type pieces of software whereby we should be smart enough not to screw up.

Unfortunately, I do think management has a hand in the failure. If they get away from the basics, then yeah we're screwed.
Patrick From An IBank Send private email
Monday, April 13, 2009
 
 
There are software developments where people have learned from their predecessors.  The chief example that gets tossed around, is the software on-board the Space Shuttle.

Tacoma Narrows is a good analogy but the real issue is the trade off between software reliability and cost.  There are some mistakes in both civil engineering and software, that are repeated ad nauseam simply because correcting them would have made the project either too expensive to build, or impossible to finish within a certain deadline.

Joel himself has written on this subject, and I think he used the example of an obscure bug in FogBugz involving "American" nationalized versions of the software, running on a Hungarian nationalized version of Windows; typing a common string in Hungarian would cause FogBugz to crash.  This is an easy (read: classic, common) mistake to avoid when you explicitly design your system to properly process international character sets but he determined it simply just wasn't worth the time and effort to fix it.

A lot of software is designed and built under similar constraints.  If I'm building a corporate web site in an environment where I know everyone will be using Internet Explorer or Firefox, I am not going to take the time to optimize my site for Lynx or the Android's bundled web browser even though, in theory, such optimization should be trivial to accomplish through CSS.
TheDavid Send private email
Monday, April 13, 2009
 
 
"That's true Walter, I recall back in the 70s it was covered in one lecture. We just had less history then. "

At that time, the stone age had ended just ten years previously.
And now,  the stone age ended just ten years ago.  Some things never change!
Walter Mitty Send private email
Tuesday, April 14, 2009
 
 
The problems of software are vastly overstated. Every company seems to have software that works well enough so that the company continues to operate.

There are a lot of unrealistic expectations about how accurately one can estimate how long it takes to develop something, which leads to most of the perceived problems.
The Contrarian Software Developer Send private email
Tuesday, April 14, 2009
 
 
The crux of the problem really lies in to simple facts.

- Your clients expect you to be completely knowledgable abou every aspect of your business.

- Most clients, or at least the management, do not understand the business and 'artistic' side of software.
em Send private email
Friday, April 17, 2009
 
 
In the link, I liked this part - ""We don't need to show the final round of changes to the prototype to the customer. I'm sure we know what they want by now."

It is assumptions like these that takes everyone on a ride at the end of which nobody has a clue as to what they wanted done in a project.

I guess it exists in other professions as well. Failure to understand the 'big picture' often leads to poor results with cost over runs
Roshan Kumar Send private email
Friday, April 17, 2009
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz