Coding Horror

programming and human factors

On Software "Engineering"

An oldie but a goodie, courtesy of Jeroen van den Bos:

A man is flying in a hot air balloon and realizes he is lost. He reduces height and spots a man down below. He lowers the balloon further and shouts: "Excuse me, can you tell me where I am?"

The man below says: "Yes you're in a hot air balloon, hovering 30 feet above this field."

"You must be a software developer," says the balloonist.

"I am," replies the man. "How did you know?"

"Well," says the balloonist, "everything you have told me is technically correct, but it's of no use to anyone."

The man below says, "You must work in business as a manager." "I do," replies the balloonist, "but how did you know?"

"Well," says the man, "you don't know where you are or where you are going, but you expect me to be able to help. You're in the same position you were before we met but now it's my fault."

Which brings to mind this cartoon Alex Gorbatchev posted a few days ago:

Software Engineering Explained

The correct answer, of course, is that there is no correct answer. Software engineering is frequently used to solve so-called wicked problems where it's impossible to visualize all the problems you'll run into without.. actually building the software. In other words, paradoxically, writing code doesn't kill projects: too much planning does!

Failure to recognize wicked projects has given Software Development a bad name. A 1994 Standish Group Report found, for example, that about a third of software development projects get canceled and half do not meet their original cost projections. Some have taken this to indicate that the state of software development is in disarray. However, it can also be read as strong evidence that there are a large number of wicked software development projects out there, trying to address wicked problems with the wrong approach.

A typical management reaction to a failed software development project is to conclude that the organization is immature and to aim for more maturity. This usually means imposing more requirements documentation, more analysis, more planning and tracking against the plan. Managers feel that more use of the classic project management processes will avert future disasters. If the failed project was addressing a tame problem, this approach will probably be beneficial.

However, classic project management practices simply do not work for wicked projects. In fact, referring again to Rittel and Webber, attempting to baseline requirements and then use an analytical approach to reach a solution is a recipe for disaster with wicked problems. These problems are resolved through discussion, consensus, iterations, and accepting change as a normal part of the process.

That article goes on to recommend the iterative development process Scrum. Any iterative process is clearly a step in the right direction. The customer really needed a tire swing but couldn't articulate that. Since we're software developers, not mind readers, the only answer is to quickly put a solution in front of the customer and keep evolving that solution based on real usage.

Written by Jeff Atwood

Indoor enthusiast. Co-founder of Stack Exchange and Discourse. Disclaimer: I have no idea what I'm talking about. Find me here: http://twitter.com/codinghorror