Second-System Effect

 Introduction

There are many principles that a large-scale-system architect must have in order to achieve the best possible result. Some of them are communication between the people that work for the project, time management, staffing of the appropriate team for the project etc. One more is discipline. On the one hand, discipline is needed between the engineer and the other members of the team and on the other hand, self-discipline is also important in order to avoid undesirable situations. Lack of self-discipline is able to lead to the second-system effect, which happens in the engineer’s second-system development [3]. Generally, it is an effect that happens to every developer and establishes his second project to be the most dangerous system to fail. However, there are several ways to face this problem which are not always efficient but can avoid the effect.

Background

In a programming large-scale-system development the architect must be able to make and execute a plan that is able to produce a cheap product as fast as possible. So, a very important principle is the communication between the member of the development team. On the one hand, a good communication with the constructor is really important in order to be able to make suggestions about cheaper implementations and changes to the design that can lead to a cheaper product. On the other hand, it is important to filter the team’s suggestions and be ready to identify what is needed in every situation that turns out in the part of building. The principle that includes all these is discipline [1].

As far as concerns the architect himself, the self-discipline problem is the first obstacle that needs to overcome. When the project development begins, the lack of experience for the architect leads to a very good first project. Superficially, this does not seem right, However, because of the absence of previous project’s experience the architect is extremely careful and each part of the project is well developed.

After the first project the developer full of confidence and experienced starts working for the second project-system. There happens The Second-System Effect [1]. According to Frederick Brooks and his book called Mythical Man-Month, the engineer’s second system is the most dangerous system that he will ever design. The reasons of the effect are given below.

Reasons

Firstly, the confidence from the first system’s success leads to the start of a more complex one that maybe is beyond the abilities of the developer. Secondly, unconsciously, the developer’s mind is full of additions that were not used in the first project and the will to use them all in the second one even if there is no need. Thirdly, it is obvious that it is not appropriate to use same functionality with the first one. However, this is a common mistake that the inexperienced developers do. Finally, another reason for the inappropriate development of the second system is that the engineer uses a complex and not so efficient way to solve a problem and as a result the system becomes over-engineered [2].

One example for the second-system effect is the IBM 709 architecture that was upgraded to 7090. There was an attempt from the developers to make it more successful but they made it so complex and full of features that only the half was used. A more representative example is the development of a system called Operating System/360. There was a tendency to use standard techniques than finding new ones and a use of bytes for not important uses(for example the use of bytes in order to provide automatic check for the leap years(366 days)). Other examples of the effect are the TESTRAN debugger and the 1410-7010 Disk Operating System, which had similar problems with the OS/360 [1,4].

Ways to avoid

It is understood that it is difficult to avoid the development of the second system. Although, there are several ways to avoid failure. Firstly, the engineer must be self-disciplined to the needs and avoid complex and not-needed functions. Secondly, it is very important for the system developer to have in mind that it is not possible to do everything in one release. One of the most common reasons of failure is the attempt to include everything in the first release. So, it is really significant to have a plan that contains the needed features and then try to improve it. Thirdly, something else that is able to help the developer is the understanding of what made the first system successful. Inexperienced developers pay more attention to the mistakes of the first system and forget what was that which led to success. Furthermore, a release can be date or feature driven, but not both. On the one hand, a date driven feature happens when the decides to work until a specific deadline when the product will be published. On the other hand, a feature drive release is a release that does not have a deadline and won’t be published until it is ready. There are successful releases for both approaches but it is almost impossible for a release to contain both [4]. Moreover, in the project manager’s point of view, it is important to choose the architect with a clean philosophy in order to reduce as much as possible the probability of failure. Finally, there is a technique called “build one to throw away” [1]. The specific technique is about the development of a system just to throw it away and build a new one. The purpose is to analyse the system’s product, find out what went wrong and finally have the experience from building two systems.

“Build one to throw away” technique is a good solution for the second-system effect that can happen because of the fact that the second system that is implemented is not really used for production but just for earning experience. However, this approach to solve the problem is time-consuming and the engineer might not work as good as for a project that would be productive.

Conclusion

The second-system effect is a common problem for all the system engineers. The first project’s enthusiasm can make the developer be full of confidence but the lack of experience might lead to the implementation of a system that is designed with a way that is not the best that could be. Although, it is difficult for an engineer to skip the second system. So, the question is what the engineer is able to do in order to keep the failure off. in order to conclude, I could say that it is normal for the engineer’s second system to be  the most dangerous project. There are many ideas in order to avoid it. The best way to make the project less dangerous is to find a way to combine all the techniques properly and provide a good result. Self-discipline is probably the key for the developer and the ability to make the proper plan and execute it as good as possible.

References

[1] Frederick P. Brooks, Jr.. 1995. The Mythical Man-Month (Anniversary Ed.). Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA.

[2] Conference Proceedings , Biggerstaff,Ted,J. , 1994 , The library scaling problem and the limits of concrete component reuse

[3] Bezroukov, Nikolai, 1999. “A second look at the Cathedral and the Bazaar.”

[4] Dare Obasanjo’s weblog => http://www.25hoursaday.com/weblog/default.aspx