Author: s1361781

Large-scale projects and their possibility of failure

Introduction

Since IT specialists started working on projects they had to face the possibility of failure. According to their scales they could be separated in three categories: small, medium and large scaled.Even if in all of them failure was always extremely possible to happen, in large-scale projects it was much more possible than in the other two types of projects.

Below, there are the reasons of this phenomenon analysed and, finally, there is a discussion about how developers could avoid it.

1 out of 9 succeed

Frederick Brooks does a very vivid comparison in his book called “The Mythical Man-Month”[2]. He compares the large-scale projects with pre-historical beasts that are inside a tar pit and struggle and fight back in order not to sink. However, it is well-known that as someone fights to avoid sinking the more he sinks.

It is a matter of fact that, nowadays, the structure of the large-scale projects has changed a lot as far as concerns simplicity. The needs from a project have become more and the developers must create constructions that are more complex and produce results that have nothing to do with past project efforts [1]. According to a UK study only 1 out of 9 large-scale projects finally succeed  and because of large-scale system failure the cost is more than one trillion dollars worldwide [3].

Why does this happen?

There are many reasons that can occur failure. Firstly, the most important is complexity. In company systems today, there are millions of computers used by people all over the world who are using the same network in order to write code and work on the same project. It is normal that one wrong life of code can cause serious problems [1]. Furthermore, as bigger as a project it is more difficult to separate it into tasks, because of the fact that it is not so easy the tasks to be divided and be equal in difficulty.

Secondly, over-optimism is capable to lead to failure. Large groups with many good programmers make the inexperienced feel confident and the experienced ones are under pressure and have to accomplish a plan that is not so realistic as it is described by the customers[1].

Furthermore, the final part of a project is the testing. Because of delays, testing is usually a mis-scheduled part and the product is not really tested in order to be ready to be delivered to the customer. Finally, another reason of failure is that in large and complex projects customers do not really know how to say what they want. They are not programmers and I believe it is really acceptable. However, they should be open-minded and try to understand and the programmer and try to think in the way he does [1].

How to avoid? – Discussion 

The first think that should be done is to simplify as more as possible the project in order to  avoid complexity. Research and estimation of complexity are probably the best ways even  if it is understood that it is difficult to measure complexity  from the beginning of the project. It is known that companies do not pay so much attention to testing. However, this is an important way to avoid failure because of the fact that in testing it is the first time that the program really runs and bugs that before were priceless after the testing might look really big [1].

Although, in my opinion, it is also important to build a team that is able to focus on the real targets, understand the capabilities and not overestimate them. The team leader must, also, inspire the team and make them do anything that it takes to follow the schedule. IT industry should also work more on finding new methods that could be used in order to be able to follow the new needs and expectations.

Conclusion

As the information technology is being evolved day by day the amount of demands is getting larger and larger. Projects are now much bigger than they used to be and companies are trying to produce the best possible result. However, most large-scale projects fail. There are may reason why this happens. Although, it is significant for the managers to understand that the creation of software has become very complex and failure is not that amazing. I believe, that, the keys to avoid failure are the stuffing of a very good team, which does not include only experience, but also responsibility and good communication and the understanding of the importance of testing.

References

[1] Denker, Ahmet. “The Challenge of Large-Scale IT Projects.” World Academy of Science, Engineering and Technology 9 (2005).

[2] Frederick P. Brooks Jr. – The Mythical Man-month: Essays on Software Engineering – Chapter 3- 1975

[3] Dalcher, Darren, and Audley Genus. “Introduction: Avoiding IS/IT implementation failure.” Technology analysis & strategic management 15.4 (2003): 403-407.

Response Article: Combining quantity and quality in large-scale projects

The specific post is a response to an article called “Combining quantity and quality in large-scale projects” by Ilias Galanopoulos.

Background

The article is based on a chapter of a book called “The Mythical Man-Month”. As it is said in the introduction the post is working on finding an answer in the question: is it better to have a small group of really good programmers or a larger one with more that are mostly average programmers [1]? In other words, what is better, quality or quantity?

According to the book’s author in a large-scale project  it is needed to have groups with many programmers that work together as a team. However, it is really difficult for a  team to succeed harmony between the members. So, the solution is hierarchy. As in a surgery team, roles must be defined to the members. For example, the surgeon is the chief programmer and the copilot in the surgeon’s assistant etc.  The main advantages of this approach are that team members can work on a same task in order to save time and that discussions,which are time-consuming,  for a problem’s solution are avoided [2].

Finally, in the post’s last subsection the author comments about the writer’s approach of the subject and writes his opinion.

Discussion

Firstly, I believe it is important to mention that I disagree with the opinion that the chief manager must make the decisions and the other member must do whatever he says. It is a matter of fact that if all the members of a group are equal then everyone would say and insist on the way that a problem should be solved and the result would be a contemporary “Babel”. However, it is significant for the chief manager to be open-minded and have the ability to listen to many opinions and discuss with all the group members and, as a result, decide which is the most appropriate  way to handle a situation.

Secondly, another point is the opinion that a solution is to use experienced programmers in important roles in the group  and bad programmers in tasks like testing. This solution could be efficient under specific circumstances. It is important for the leader to find the good programmers that will play the leading roles in the team and not to “sacrifice” good programmers in not so important tasks. Furthermore, it is also significant the not so good programmers not to feel like they belong to another team and be in an environment that do not underestimate them and pay attention to their opinions. This has as a result the team to communicate well and maintain in a good vibe. Under these circumstances I could say that I agree with the author in using this solution.

Finally,  in my opinion, the best way to manage a team in a large-scale project is mentioned at the end of the post. I agree totally that the best way is the divide the team members according to their speciality [2,3]. Like testers, engineers and administrators. However, I disagree with the fact that the post’s author does not analyse this solution as much as he could but insists in not so efficient ways to manage groups.

Conclusion

If I wanted to come to a conclusion, I could say that the post’s author has done a good job in the background analysis of the team management and some of the best ways to do it. Moreover, I think it would be better to write more about his opinion in the last suggestion.

 

References

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

[2] Galanopoulos Ilias, 2014 , Combining quantity and quality in large-scale projects,  https://blog.inf.ed.ac.uk/sapm/2014/02/14/combining-quantity-and-quality-in-large-scale-projects/

[3]  Software Engineering: Principles and Practice – Third Edition – Hans Van Vliet – Chapter 3 – 2008

 

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