Software Engineering … The Other Way

by Simon. Average Reading Time: about a minute.

Software development is an often complex affair, beset by a multitude of difficulties ranging from talentless developers, feature bloat, stakeholder politics and poor planning.

The following cartoon, by blogged about by Alex Gorbatchev, is a modern take on an old, yet still relevant, problem; the reasons for software engineering failures.

Software Engineering Explained

Designing systems today is difficult because there is no consensus on what the problems are, let alone how to resolve them.

Software engineering is often used to solve complex problems, problems where it’s impossible to visualise all the difficulties you’ll run into without actually building the software. This has led to what is known as Wicked Problems. In other words, writing code doesn’t kill projects, too much planning, too much functionality and too many stakeholders do!

Wicked problems arise when an organization must deal with something new, with change, and when multiple stakeholders have different ideas about how the change should take place.

Every wicked problem can be considered a symptom of another problem.

The article goes on to recommend the iterative development process, first proposed by Takeuchi and Nonaka in “The New New Product Development Game” called Scrum. An iterative, as opposed to a Waterfall, process is clearly a step in the right direction. The customer really needed a simple tyre swing but couldn’t articulate that in a meaningful way. Since we’re software developers, not Zen Masters, an answer is to quickly develop a solution in for the customer and keep evolving that solution based on real usage. That way, we can get from the plank to the tyre swing without the need for the roller-coaster ride of complication.

This article has been tagged

, , , , , , , , , , , , , , , , , , , , , , , , ,

Other articles I recommend

The Cathedral and the Bizarre

The Cathedral and the Bazaar is an essay by Eric S. Raymond on software engineering methods, based on his observations of the Linux kernel development process and his experiences managing an open source project, fetchmail. It examines the struggle between top-down and bottom-up design.

Hansen’s User Engineering Principles for Interactive Systems

The ‘feel’ of an interactive system can be compared to the impressions generated by a piece of music. Both can only be experienced over a period of time. With either, the user must abstract the structure of the system from a sequence of details. Each may have a quality of ‘naturalness’ because successive actions follow a logically self-consistent pattern. A good composer can write a new pattern which will seem, after a few listenings, to be so natural the observer wonders why it was never done before.

Adobe AIR for JavaScript Developers – O'Reilly Pocket Guide

Mike Chambers announced at the onAIR tour London event last week that he would be releasing an electronic version of the Adobe AIR for JavaScript Developers pocket book, by the publishers O’Reilly, under Creative Commons licence terms. Well, good to his word, you can download the pocket reference from the Adobe onAIR website.

  • Simon,

    Here’s an interesting follow-up on how people can get hung up implementing an iterative development process to the point it is actually a small series of waterfall developments (incremental vs. iterative). Interesting perspective:


  • bob


  • duplicate…

  • It’s been a couple of years, but I want to make a notice that I DID NOT create this cartoon. I have blogged it a few years back, but I’m not the author.

  • Sorry Alex, I wasn’t aware it was not created by you. I have updated the post.

  • Sorry Alex, I wasn't aware it was not created by you. I have updated the post.