How to Avoid the Second System Syndrome
The second system syndrome is a phenomenon that happens every time a person or company tries to rewrite a successful software for a revamped second version.
The syndrome is characterized by lots of promises (the next version will be the best ever…), long release cycles, and usually failure from the part of the developers to create something that is even close to the expected.
The same set of events have been observed throughout the industry in several occasions. A company that goes through this kind of cycle either has to go back to a previous version and stop development of the much awaited new incarnation of the product, or in the worst case becomes completely irrelevant.
Of course, this kind of syndrome doesn’t happen only in the second version of a software (the 2.0), it can happen in any stage of the lifetime of a software product. For example, Netscape rewrote their browser between the versions 3 and 4, and almost killed it. Microsoft tried to rewrite Windows several times in the last 20 years. With the only exception of the launching of Windows NT, which was a completely different product at the time, all planed rewrites took longer than expected and resulted in an inferior version being released.
From the experience accumulated by companies of all sizes, there are a few recommendations that can help avoiding many of the mistakes mentioned above.
Don’t try to make everything better at the same time: one of the reasons for defeat by the second system syndrome is having no clear goals. If you just setup to create a new version of your software that is better in any way, this is mostly a recipe for failure. There is an infinite number of improvements you can make to a program. You won’t have time to make them all work.
To avoid this danger, start by clearly defining an area of the system that will be improved in the next version. Maybe you can add a second area, but the more focused you are, the better your results will be.
Another helpful suggestion is to concentrate on specific features, not on the general feeling of the application. Features can be implemented, abstract ideas cannot.
Internal Changes
Another reason people feel the need to rewrite a program is the idea that its source code is ugly, and should be changed. While this may be a good reason for making internal improvements, it is rarely a reason for rewriting a program.
Remember, users don’t see your code. They are not attracted to your program because of the clarity of the source code. All they see is the implemented features of your application. While you have to strive to write maintainable, clean code, such an advantage is not worthy the price of a complete rewrite.
Conclusion: instead of being too ambitious and disappoint your users, it is much better to provide great new features in each version of your software. Avoid the second system syndrome: users will be happier and you, as a developer, will have a much better time.
Similar Posts:
About the Author
Carlos Oliveira holds a PhD in Systems Engineering and Optimization from University of Florida. He works as a software engineer, with more than 10 years of experience in developing high performance, commercial and scientific applications in C++, Java, and Objective-C. His most Recent Book is Practical C++ Financial Programming.
