Author: Ilias Galanopoulos

Introduction

The definition of software maintenance is the following: “Software maintenance is the modification of a software product after delivery to correct faults, to improve performance or other attributes, or to adapt the product to a modified environment” [1].  However, after a brief search in the literature somebody can find some really surprising facts about maintenance in modern software. Some of them are: “software maintenance task is the most expensive part of the life cycle” [1] or  “maintenance accounts for more than 90% of the total cost of software” [2].

This article will try to briefly describe what is software maintenance focusing on maintenance time and costs. Firstly there is a chapter explaining why maintenance is so necessary and which factors affect maintenance time and costs. Then some of the most common solutions in order to reduce maintenance are listed. Finally, a surprising fact about maintenance is presented and there is a discussion about modern development techniques and whether they result in less maintenance time.

 

Overview

Software maintenance is an essential part of software development. Even if we assume that we can design and build a perfect system matching all requirements, maintenance will be necessary sooner or later. The reason for that is that there is nothing unchangeable in the world, especially in the world of software. Designing and developing new software is neither time nor cost effective. So in most cases, the only feasible solution is to maintain existing software.

New hardware technologies are an important challenge for software designers. Software should be constantly modified in order to take full advantage of new and more efficient hardware systems. Moreover, new software technologies make change inevitable. New features or functionalities have to be added in order to make system up-to-date, otherwise even a perfect system will be soon out-dated.

Maintenance is a tough, costly and time-consuming job. As mentioned above maintenance is the most expensive part of program’s life cycle as it could be up to 90% of total costs. However, there are several parameters affecting maintenance time and costs. System size and number of users is one of the most important. Large systems with many users have to be frequently modified and repaired. The cost of failure in such systems would be disastrous, so all necessary operations should be performed in order to guarantee that these large systems are reliable and 99.999% available. System age is another important factor. Older systems need frequent maintenance in order to remain operational and withstand competition. New features have to be added in order to ensure that service provided is of high quality and that they can equally compete with similar systems.

 

Reducing maintenance

 According to some recent research [2], understanding is one of the most time-consuming maintenance tasks as it may take up to 60% of the total maintenance time. Understanding is the process of trying to identify where a change should be made and how this change should be. The main reason for the –incredibly- high amount of time spent on understanding is lack of documentation. Older systems are usually poorly documented and most of their developers are now retired or not working on these systems any more. So, new engineers waste so much time trying to understand how these systems work. Therefore, good documentation would reduce maintenance time and reduce maintenance costs as a result. Moreover, really good programmers will be able to operate in their full potential as they will focus on finding the optimal solution instead of wasting time trying to read poorly documented code.

Old, unused and dispersed code is also a great problem for maintenance. Most systems, especially the older ones, have large parts of code which are not useful any more. In many cases code is also dispersed in many files and different components making maintenance a really difficult job. So eliminating “dead” code is one of the first steps that should be taken in order to make maintenance less consuming. Reorganising code and grouping files could be also beneficial for maintenance time. In general, less complex and more well-structured code is the key for improved maintainability.

 

A controversial fact

 Dekleva’s [3] study demonstrated a really surprising and controversial fact about software maintenance. According to his empirical study there is no evidence proving that modern software development techniques have resulted in less maintenance time. On the contrary, in many cases maintenance time has increased over the last decades [2], even though new software development techniques have been introduced. Dekleva acknowledges the fact that maintenance is now easier and requires less effort and that even complex changes in an existing system are now feasible.

Dekleva’s fact sounds strange but it reflects reality. In the 1970’s maintenance accounted for about 50% of a project’s time. Nowadays it is usually up to 90% [2]. Maintenance was always an indispensable part of the software development process and this will not change. All systems need some changes in order to remain operational and maintenance and enhancement of existing systems is usually more effective than building a new system from scratch. But the question is why all these new software development methodologies are useful if they cannot reduce maintenance time and costs?

Modern software methodologies made maintenance easier and more flexible. In the previous decades, older development techniques allowed a limited amount of modifications and changes in software. So the amount of time spent on maintenance was not as high as today just because we could not change much more. Only a few maintenance operations could be done in older systems and most of them were just some minor improvements.

Nowadays, changes are more complex because we have to ability to make major changes in existing systems. Many new features can be added, large parts of the code can be modified and systems designed years ago can be still operational. In this way, Dekleva’s fact should not surprise us but on the contrary should be seen as a really positive fact. Modern development techniques offer a variety of tools and allow us to constantly improve existing systems modifying them according to our needs. In other words, we spend more time on maintenance because modern development techniques have pushed maintenance limits.

 

Conclusion

Software maintenance is a crucial part of software life cycle. All software systems need constant maintenance in order to remain operational and reliable. Larger and older systems are those which need more maintenance operations and functional enhancements. However, maintenance is a time and cost consuming task. Good code documentation, good code structure and less complex software are some of the most common solutions in order to achieve lower maintenance time and costs. Finally, it was demonstrated that modern development techniques do not reduce maintenance time but this is not a negative fact. Modern techniques allow us to make more complex changes and more crucial modifications keeping software updated.

 

[1]. “Software maintenance – An overview” –  Carl Allen – http://www.bcs.org/content/ConWebDoc/3063

[2]. How to save on software maintenance costs – Omnext white paper, March 2010

[3]. “The influence of the Information Systems Development Approach on Maintenance” – Sasa M Dekleva – MIS Quarterfly, Vol 16, No 3 – September 1992 – pages 355-372

 

This is a response article to “Why Pair Programming Is The Best Development Practice?”.

Introduction

The author [1] made a very good job describing pair programming and demonstrating advantages and some disadvantages. However, the original article [1] was too optimistic about the benefits of pair programming without taking into account some important problems that may arise.

In the following paragraphs we will discuss about advantages and disadvantages of pair programming followed by a conclusion at the end. Most advantages are already mentioned in the original article but in this response article they will be summarised trying to underline the most important arguments for pair programming. The main contribution of this response article is the discussion about disadvantages. Many negative aspects of pair programming are not mentioned in the original article, so there was a need to provide some extra arguments against pair programming in order to have a broader range of ideas about this programming technique.

Discussion about advantages

Most pair programming advantages are already mentioned in the article [1]. Pair programming can be a very good way to reduce errors and bugs in code, as two pairs of eyes are always more efficient than one. Moreover, two programmers can solve a demanding problem more easily [3], especially if they combine different skills and programming techniques. Teamwork ability, communication and cooperation skills are also improved by pair programming. Pair members learn how to work together under any circumstances and find solutions to any problems under consensus. This is very important especially for large-scale projects where teamwork and cooperation between group members is essential. So, pair programmers have already an advantage when working in such projects as they can handle the situation more easily. Finally, pair programming is an excellent way of exchanging knowledge and tutoring inexperienced programmers. A young programmer can be benefited when programming alongside an experienced one, thus helping him improve his skills much faster.

Discussion about disadvantages

Pair programming may be advantageous for many people, but not for everyone. Many people are more productive when programming on their own than working in pairs. The reason for that is that they do not like to think out loud or they just need some time to read code and think on themselves. And for those who claim that communication skills can be improved and that everyone can become familiar with pair programming the answer is simple: Not everyone can have excellent communication skills in the same way not everyone can become an excellent programmer. Therefore, not everyone can be equally productive when working solo and when working in a pair.

Moreover, pair programming requires an excellent synchronisation between pair members, even in the simplest things. Both pair members have to start and stop working exactly at the same time; they should have break together and they should get their day-offs or holidays together [2]. So, what is going to happen if one of the two has to be absent for a few days? If the other guy keeps working without its pair, then that kind of programming will not be very…pair. On the other hand, supposing that another programmer comes as a replacement for the absent guy, it will take him some time to adapt to the project and become familiar with his new pair. And what if there not available programmers to replace the absent guy [3] or all of then work with their own pairs? So, pair programming in some cases is ineffective as a number of problems may appear.

Conclusion

In conclusion, pair programming is something that everyone should try. Some may find it extremely interesting or helpful; some others may hate it. This is absolutely reasonable as every person has a unique personality and a unique coding style. However, the reason for writing this response article was to point out some negatives aspects of pair programming that were not covered in the original article. In my opinion, the author has overrated the benefits of pair programming while he/she has not taken into account some problems that may arise. I personally believe that pair programming can be very useful in some circumstances, such as when tutoring an inexperienced programmer or when writing a crucial part of a program and more than one persons are necessary in order to find the optimal solution. But in most cases coding is a lonely job…

References

[1]. https://blog.inf.ed.ac.uk/sapm/2014/02/17/why-pair-programming/

[2]. http://mwilden.blogspot.co.uk/2009/11/why-i-dont-like-pair-programming-and.html

[3]. The Costs and Benefits of Pair Programming – Alistair Cockburn, Laurie Williams – Extreme programming examined – 2000 – ISBN:0-201-71040

Introduction

Most software managers agree that small groups of experienced and really capable programmers are far more effective than huge groups of programmers working on a project. They also claim that they can easily coordinate a small group of efficient programmers while in big groups communication is always a big problem. However, some large software projects are too large to be completed by a small group of programmers, even if this group contains some of the best programmers available in the industry. This article focuses on one of the most important dilemmas in Software Engineering: quantity or quality is more important in large-scale projects? Is there any solution that could combine both of them and bring the optimal results?

Summary

Fred Brooks in his book “The Mythical Man-Month”-Chapter 3 [1] presents a study conducted by Sackman, Erikson and Grant about programmers’ productivity. This study proved that there is a significant difference between good and bad programmers in terms of productivity. A good and experienced programmer can be up to 10 times more productive than a bad or inexperienced programmer, even though the salary paid to an experienced programmer is usually double the salary an inexperienced programmer gets. Therefore, managers would prefer to hire a couple of really good programmers and allocate tasks to them, as this would be more cost effective.

However, large-scale products require thousands of work hours and cannot be completed just by small groups of excellent programmers. So, hiring more programmers, even if they are mediocre or inexperienced, is absolutely essential for large projects. But this poses a new challenge for projects managers. They have to find solutions for combining good and bad programmers in an efficient way. They also have to coordinate a large number of persons and a large number of groups. Finally, communication and decision making between groups and their members is also a difficult problem for managers.

Harlam Mills proposed a solution [1] about such large projects. According to Mills all large projects should be divided into smaller tasks. These tasks should be allocated to small groups of roughly 10 persons which have a specific hierarchy. Mills states that these groups should operate like a surgical team where a surgeon is surrounded by anaesthesiologists and nurses, each of them having a specific role. The structure of this team should be the following:

 

• The surgeon or the chief programmer. He is the team leader and the person who designs the program, writes the code, runs tests and writes documentation. He should pose versatile skills and significant experience.
• The copilot. He is the surgeon’s assistant. He should be able to do surgeon’s work and he has similar skills but slightly less experience. Copilot can also offer advice to the surgeon but the surgeon in the only person who takes all crucial decisions.
• The administrator is the person who handles human and material resources. The surgeon should typically take decisions about personnel, money or machines but he rarely has enough time to do it. Therefore, the administrator is responsible for these issues and also he is the person who is in contact with other groups.
• The editor is the person who writes the documentation. The surgeon usually prepares a draft of the documentation and then it is the editor’s job to criticize it, rewrite it and provide references.
• Two secretaries. The administrator and the editor should have a secretary. Administrator’s secretary usually is responsible for correspondence.
• The program clerk is responsible for keeping technical records of the team. According to Mills proposal all files are visible to all team members. So, the clerk collects all input and output files and stores them in a chronological archive.
• The toolsmith is responsible for interactive services such as text editing, file editing and debugging. He should reassure that all this services are working properly as they are essential tools for the team.
• The tester is the person who runs tests and provides assistance in code debugging. The surgeon is the person who writes the tests but a tester is necessary to run these tests and provide feedback about the correctness of the code.
• The language lawyer is a programming language expert. He is responsible for finding an efficient way to use the programming language in order to solve demanding and tricky problems. He should be a system designer and usually two or more groups share one language lawyer.

 

According to Mills this structure has two main advantages compared to an ordinary team of two programmers. Firstly, in an ordinary team the work is divided so each programmer needs its own disk space and access. However, surgeon and copilot work together thus saving material and time [1]. Secondly, in a team of two programmers all disagreements have to be solved by discussion until they reach in an agreement or compromise; but this is often time consuming. On the other hand, the surgeon is higher in the team hierarchy so he is the one decides and takes the responsibility of decision-making. This hierarchy is much more effective in software projects [1].

Discussion

Mills proposal has many positive ideas if examined in an abstract way. The main point of Mills idea is hierarchical structure. This structure is nowadays a commonplace for almost all projects. In each organization or group there should always be a person who will always take a decision.

Non-hierarchical structures are not efficient as group members always express different opinions and proposals. This is reasonable as each person has a different understanding of the problem and a different solution. But in such groups one solution should be decided so that everyone should work on it. In a non-hierarchical structure decision making should be made under discussion, cooperation and team consensus. However, this is ineffective, time consuming and in some cases impossible. Therefore, a team leader is always essential in order to coordinate and team members and take a final decision when it is necessary.

According to Brooks [1] when more people are added to large-scale project overall productivity falls especially due to bad communication. Mills proposal gives a solution to this problem. Mills proposed structure takes advantage of small groups efficiency in order to deal with large scale projects. Combined with the benefits of hierarchical structure mentioned above communication between groups is much easier following this model. Chief managers can communicate and give instructions to group leaders, the surgeons, and they can also coordinate their group giving appropriate instructions. Moreover, following this proposal the best and more experienced programmers are in the key positions designing and writing the code, while less experienced or bad programmers take the editor, clerk or tester role. Therefore, good programmers can focus on the important part of the project –design and coding- and at the same time they do not have to waste time in other tasks.

However, Mills proposal is not always effective if examined in a more detailed view. Hierarchical structure is considered essential for all large projects but the question is how can we divide personnel into smaller groups and how we can organize these groups. Mills’ surgical team is not suitable for all problems. Some projects may require teams with more programmers and less auxiliary personnel such as clerks, testers or editors. According to Hans Van Vliet’ book [2] groups can be divided according to people’s specialties. For instance a group could contain more than two software engineers, web developers or network administrators working on different parts of a specific task, under the guidance of an experienced chief programmer.

To sum up, Mills proposal offered an excellent approach on diving large-scale projects to smaller tasks undertaken by small groups of programmers. It also demonstrated the importance of hierarchical structures and showed an efficient way of using experienced programmers without wasting their time on time consuming tasks. However, groups’ organization could be different as more programmers may be required. Therefore, Mills plan should be the basis for all large-scale projects but group division should be decided according to the needs of the problem.

References

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

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