In yesterday’s post I discussed Fred Brooks’ classic book, “The Mythical Man-Month.” One of the chapters of this book focuses on what Brooks calls “The Second System Effect.” In brief, the second system effect goes like this:

  • You build a system. It works, satisfies the customer’s requirements, and everyone is happy. 
  • You then move on to build a second system. In this system, you put in all the features that you didn’t get around to in the first system. You include a laundry list of new customer requirements. 
  • Smash cut to the end: the system is a disaster. Requirements pile on requirements and continue to change through the project. Features pile on top of features. The architecture becomes baroque, the code becomes unmaintainable, and if the the team manages to produce something at the end, nobody wants to use it.

So what do you do about it? Brooks suggests that the first step is to be aware of the tendency, and to take steps to fight against it:

How does the architect avoid the second system effect? Well, obviously he can’t skip his second system. But he can be conscious of the peculiar hazards of that system, and exert extra self-discipline to avoid functional ornamentation and to avoid extrapolation of functions that are obviated by changes in assumptions and purposes.

How does the project manager avoid the second system effect? By insisting on a senior architect who has at least two systems under his belt. Too, by staying aware of the special temptations, he can ask the right questions to ensure that the philosophical concepts and objectives are fully reflected in the detailed design. 

(Quote from “The Mythical Man-Month” by Fred Brooks, 1978, p 58)

That’s not really a lot to go on, especially in the face of starry-eyed stakeholders with dreams of a perfect system, but at least if you’re aware of the issue you can do what you can to reduce the issues and keep your system clean.