In 1975, computer architect Fred Brooks published a series of essays on software engineering and project management called “The Mythical Man-Month.”

These cautionary tales and inevitable realities not only stand the test of time, but also can crossover to many applications.

In this second article I will talk about is his essay “The Second-System Effect”. The basic theme of this is that while the first attempt at most programs or systems will be small, clean and perhaps under-powered, the second attempts will swing far the other way.

Image By Gerd Altmanna via Pixabay

As an engineer or programmer works on a first system, the ideas and logic that comes to them is derived from the specification of the task or project.

The biggest task is to create a complete system and cover all of the functionality that is required.

While it’s beneficial for the design to be clear and easy to follow, that doesn’t always mean it isn’t complex or full-featured.

In the end, what’s most important is that the final product is functional and does everything it’s supposed to do.

As the project matures, however, all the time that is spent working on it leads to a lot of thought about how it could be improved.

Customers, sales people, executives, and others with influence over the project all offer their opinions about what they think needs to be added.

When the time comes to create a successor to the original project, a new specification is required. It is at this point that all of these ideas and suggestions will resurface.

This is also where a lot of the elegance in the first system goes away.

New features and complexity is added, which in turn can make the logic cumbersome. This phenomenon is often referred to as “feature creep”.

As the existing program base is modified and scrutinized, refinements may be made to areas that don’t need them, compromising the integrity of time-tested core segments of the program.

The user interface may end up becoming cluttered and unattractive as all of the new features need to be represented, causing it to be more difficult to use.

With the first system, 80% of the features may be commonly used, whereas with the second system, that number may drop to be as low as 20%.

So while the second “improved” system may be able to do a lot more, all the effort that went into adding many new (but seldom used) features often comes at a high price.


As a result, the reaction and feedback to the second system may be less than stellar.

Take Windows 7 and Windows 8 as examples of a first and second system. Windows 7 was generally received with good reviews. Windows 8, however, was almost universally panned.

The changes were pretty drastic, and a lot of complexity was added as Microsoft attempted to re-brand programs as “apps”.

Over time this second system will mature. Updates and patches will be applied to reverse course and reach a stable and acceptable equilibrium.

An example of this is the transformation of Windows 8 into Windows 10. Now Windows 10 is considered a successful operating system. Updates moving forward beyond the second system often continue to trend in the right direction.

The only thing to watch here is that you don’t create “bloatware” – keeping all of the legacy features intact just in case someone wants to use them. Sometimes it is best to cut obsolescence out.

In summary, when starting a second effort, be mindful of doing too much. Keep in mind why the first system was successful and consider using experienced programmers who have worked through the situation before. Don’t think it can’t happen to you!

Written by Carlo Zaskorski
Controls Design Engineer and Freelance Blogger

Have a news tip? Share it with us here.
Have a question on this topic? Click here to scroll down to the comment link
Enjoy the benifits of membership! Insider news, rewards, & more: Patreon.com/automation

Carlo Zaskorski

Carlo Zaskorski is a freelance writer for The Automation Blog who spends his days as a principal design engineer in the boiler/burner industry, his nights as an adjunct professor teaching PLC programming at College of DuPage.
Carlo Zaskorski


Click HERE to scroll down to view or leave comments


Leave A Blog Reply Here

Please enter your blog comment!
Please enter your name here