You are part of the problem

by daniel on September 24, 2008

As described in the Man-Month Myth, there are many times where the system designer is part of the problem. He calls it the second system effect due to the nature of people trying to do better the second time they do something.

Quoting the book: “

As he designs the first work, frill after frill and embellishment after embellishment occur to him. These get stored away to he used “next time.” Sooner or later the first system is finished, and the architect, with firm, confidence and a demonstrated mastery of that class of systems, is ready to build a second system.

This second is the most dangerous system a man ever designs. When he does his third and later ones, his prior experiences will confirm each other as to the general characteristics of such systems, and their differences will identify those parts of his experience that are particular and not generalizable.

The general tendency is to over-design the second system, using all the ideas and frills that were cautiously sidetracked on the first one.

The designer will bring bells and whistles from previous experience to the next one. This can be helpful and be destructive at the same time:

  • Helpful because some of the ideas are relevant to this project and can actually make it a better one. This can add versatility, flexibility, and needed features.
  • Destructive because it undoubtedly make it more complex, requiring much more time and effort, requiring much more management  and most of the time making the product late.

For example, in situation I was involved, this could have happened but didn’t.

We were required to format different input files (text, binary, etc) to one common format so it could be processed by an analysis engine. The text format was easy to manage as we had experience with a format management system from Informatica (link). The binary files were the problematic ones due to them being binary packed fields, where byte boundaries were not kept.

The software engineer wanted to write a code generating engine, where a file with the parameter definitions will be parsed, and the engine will create a C# class for decoding the file. My initial thought was that it bee a great idea because it will add capabilities to our engine that might be reused in the future to replace the external engine. This engine will be a second generation of code creation engines, reusing ideas from previous projects. Further discussions revealed the problems: it has never been done for this complexity, it wouldn’t have the conditionals required for correctly parsing all possible cases, no testing tools will be available and most important – it will add 4-6 weeks development time. Due to the last issue and the risk involved, it was decided to take the path with lesser risk with the external tool. an

At the end the decision was the correct one, because the project was late by several months, even without adding the writing of a new engine.

As you can see, taking yourself out and thinking of the best interest of the project can help in making critical decisions.

No tags for this post.

Comments on this entry are closed.

Previous post:

Next post: