« Passing Judgement | Main | Analogy - Definitive or Provocative? »

"Software is Different"

This is the refrain heard from almost every software team when some sort of management process is being considered. The goal is, of course, to avoid what I assume software people believe is an assault on their independence and freedom or perhaps merely a desire to make the bean counting process nerds go away.

While this approach achieves these goals, it has some unfortunate side affects. First, it keeps software project management somewhat retarded and isolated as Glen Alleman points out in his article about the "Not So New Paradigm". Second, it avoids capturing data to know if something is better or not so there is no way of knowing if any one of the "Not So New Paradigm"s are actually working.

The interesting thing is that this ploy usually does succeed, because after all software IS different, or at least sort of different, at least as different from manufacturing as say construction is, which is to say that it is not all that very different in some major aspects, but does have important distinguishing characteristics... When you look closely enough at things they are all different.

The point I'm trying to make here, and one which at least to me is not coming across clearly so far so I'm going to boil it down in this last paragraph, is that for endeavors such as managing a project the approach should be to look first for common ground - look at general classes of problems and their solutions. Then look at ways those solutions can be applied to the specific circumstances. The software people are right, one size does not fit all, but that does not excuse a team for walking around naked. Find a tailor or do it yourself. And be careful not to end up like a certain famous emperor.


Comments (1)


Software IS different in some aspects. Forgot the cost of goods manufacturing issues, those are red herrings. You can't look at software. It's one or two levels removed from the "real" product in that only the User Interface and the reports can be seen by humans. Were roads, launch vehicles, houses, circuit boards full of chips are tangible in ways software is not.

That said there must be a way to make software "tangible" for assessment of progress to plan. Agile does this in some ways by 100% testing. But in the end the real problem with software and what makes it different is that there are poor specification lanaguage. The specification of function is vague and requires human validaion.

For the design of a house I can get within 80% or 90% of the design and construction on paper, the final 10% to 20% I have to tell someone in deatil what to do with my kitchen cabinets or landuary room shelving. For a propulsion system I can specify nearly the exact behaviour needed to guide the space craft to its orbit around Mars on paper.

For the software on board the Mars lander on in my home network, it's a waste to time to over specify since I can change the design - most of the time when I decide it's not turning out the way I want.

Post a comment

(Comments are moderated to fight SPAM and will be published after I have a chance to approve them. Thanks for waiting.)


The previous article is Passing Judgement.

The next article is Analogy - Definitive or Provocative?.

Current articles are in the main index page and you can find a complete list of articles in the archives.

Creative Commons License
This weblog is licensed under a Creative Commons License.
Powered by
Movable Type 3.34