Author: s1041645

1. Introduction

People are the most important asset in any type of project. The quality of the product is strongly dependent on the teamwork: “a good team builds a good product, a bad team builds a bad product” [1].

The main cause of a bad team is people themselves. It is usually enough for a single person to be bad to cause problems and reduce productivity. In this article I will discuss the concept of having a “bad apple” in your team and contrasting discussions and how to deal with them. I will also give examples from my experience I gained throughout my years of university.

 

2. Background

The “bad apple” concept refers to a bad fruit ruining all the other fruits next to it. In software engineering, this concept applies when the attitude of a team member affects the entire team such that the productivity decreases, problems arise and the quality of the product is jeopardised. In his article [2], Will Felps categorizes the types of human “bad apples” and suggests solutions of dealing with them.

He says there are three types of bad team members:

• The withholder of effort: avoids doing work, does not complete tasks and does not take responsibilities
• The affectively negative individual: always has a negative mood and attitude
• The interpersonal deviant: proves disrespect towards his colleagues by having an inappropriate behaviour

Felps gives three ways to deal with these individuals:

• Motivational interventions: upper management interventions or public criticism
• Rejection: excluding from discussions and removing responsibilities
• Defensiveness: revenge, good mood maintenance, distraction, denial and withdrawal from the group

It is possible that although the team doesn’t have a “bad apple”, diverse opinions can cause disruptive teamwork. In his article [3], Alistair Cockburn emphasizes how the difference and non-linearity between people have become an important factor when talking about application development. He presents fourteen concepts that summarize the human presence in a project. I believe that the most important facts that must be considered when assessing the success of a team are the following:

• Trust in people to do what is necessary.
• Adjust for people making mistakes.
• People act according to their reward.
• Recognise the presence of dominant personalities.
• Let people work in unpredictable sequences
• The communications load can soon dominate the project.
• Software creation is limited by the ability of people to express their thoughts.

 

3. Experience

Throughout my university years I was part of a lot of group projects that aimed to teach us the importance of teamwork and organisational skills. However, no one actually instructed us how not to be the “bad apple” in our team. It is very likely that a lesson wouldn’t have helped us anyway since a lot of students would not have taken the advice. But in my opinion it would have at least made it easier for the good team members to confront and deal with the bad ones.

Every single team I was part of either had one or more bad apples in it or had people whose contrasting opinions lead to friction between colleagues. I have seen how the whole team has to suffer just because of one individual or how opposed attitudes put at risk the success of the project.

3.1 Slacker’s Effect

From experience I can say that in a university projects the bad apple usually comes in the flavour of “the withholder of effort”. Simply put, every team has a slacker. Such an individual can be observed as not attending the team meetings, bringing outsiders during the team discussions that distract everyone else or even find silly excuses for not being able to cope with pressure.

The worse thing about this situation is when you don’t see the bad apples from the beginning. Such an individual can be able to convince the team he is a hard worker and a good team player. The problem appears when you discover he is the exact opposite half way through the development time and adding more resources or removing people is impossible. In such cases disaster can be impossible to avoid.

The main effect of having such a person in my team caused “perceptions of inequity” between the other members. Everyone was comparing their contribution efforts with his and were considering the idea of being under-rewarded in the end. This can lead to the other team members to reduce their contributions and compromise the project themselves.

In a university environment, the motivational intervention by criticising the laziness to the supervisor would seem the most straightforward solution for such a situation. However, it doesn’t work very well since usually the supervisor does not take any action. I still don’t know if that’s because the whole point of doing a team project is learning how to deal with these situations (does this mean that the other solutions should be embraced?) or that the supervisor is too busy to get involved.

From experience, the best solution for such a situation is for the rest of the team to keep a strong relation. Having a good team leader can always help to eliminate interactions with the negative member and reassign responsibilities.

3.2 Diversity of People

I have also been in the unpleasant situation where the team had more bad members than good ones. Moreover, they were all good friends that didn’t take things seriously and were very reluctant in discussing each member’s responsibilities and taking advice from the others. I can’t put them in one of Felps “bad apple” categories since they were neither rude or with a negative attitude. With respect to their work, they finished in the end but the quality was very poor.

With only two of us left to do the rest of the work we realised immediately the seriousness of the situation we were in. Talking to the supervisor was not a solution since they were showing some progress on their work. We couldn’t possibly reject them either since they represented more than half of the team and the workload was too high.  We ended up fulfilling our tasks, keeping a positive attitude and hoping they will eventually finish the work they assigned to themselves. Disaster did strike us when our product failed to work during our presentation. Luckily we were given a second chance and my colleague was able to fix the bug caused by the bad members in time for our second demo.

This situation can be characterised by having team members with different attitudes and opinions with regards to work rather than having “bad apples”. Looking at Cockburn’s concepts, it was important for us to recognise the different personalities. We had to trust the others to do their necessary work and make sure that we can fix mistakes that might occur because of them. Moreover, if they wouldn’t have worked in unpredictable sequences or be able to express their thoughts in their own way the product might have not been finished at all.

 

4. Conclusion

In conclusion, every team will have a “bad apple” or occasionally more. Sometimes the “bad apple” might not be visible from the beginning and this could lead to problems later on in the development cycle. Other times, the “bad apple” effect is not very strong but differences between people’s personalities and attitudes can increase product creativity but also disrupt the teamwork.

Felper categorised the ”bad apples” and solutions against them in his article while Cockburn emphasises the importance of non-linearity between people. In both cases it is important to know how to deal with that particular situation. In a university environment it is very likely to encounter such situations while being part of group projects.

 

5. References

[1] Edwin Dando, “Behaviour Dynamics in Agile Teams”, July 2013

[2] Will Felps, “How, When and Why bad apples spoil the barrel: Negative Group Members and Dysfunctional Groups ”, 2006

[3] Alistair Cockburn, Growth of Human Factors in Application Development”, 1995

Introduction

This is a response to the article “Version Control: Important for Individual Projects?”.

The article tackles a subject that should be of great interest to all the students in this course. Each and every one of us should ask ourselves the question in the title. Hopefully all of us who have already finished the implementation part of our thesis project have used version control. The ones that will be doing their project next year should start thinking about the advantages of using version control.

In this article I will emphasise both my agreement and disagreement with the original paper. Where necessary I will support my statement using examples from my own experience.

I have recently finished an Industrial Placement at a software design company. This placement represented my master thesis project and I was thus the only developer. The company I worked for was using version control for every single project and they advised me to do so with mine. After this experience, I strongly believe that version control should be used in any software project including the ones in which there is only a single developer. Actually, as Saikat Basu says in his article [1], version control should be used in “anything that has to do with typing an alphabet on a document”.

Discussion

I agree with the author with respect to the fact that version control is “essential to maintaining an organised structure” by allowing all team members to work on the same source code from different locations. However, it is important to emphasize that this is an advantage of having an online shared repository more than using version control. During my time at the company I was able to see how people on different continents were successfully using an online shared repository combined with version control to work on the same project. Moreover, it was a very good way to share ideas and documentation. Although version control allowed them to keep track of changes and updates, this would not have been possible without a shared copy of the project.

The author states that “These advantages do not apply for an individual developer”. It is not clear if in this context the individual developer can’t take advantage of using version control or an online repository. I believe that having an online repository is useful even for individual projects since it allows you to have a distributed backup. Some people prefer to use the company’s computer while they are at work and their own when they are home. Having an online repository will allow you to work on your code from different systems.

I agree with the author that reverting back to older working versions is very useful for any type of project; individual or teamwork. Throughout my project I was often updating code, improving algorithms and adding new features. Having older versions backed up assured me that even if my changes break the code I could always return to the original state of the project. I personally comment out code that I don’t want to use until I am sure that it is not needed anymore. But I have seen people that simply delete their code before writing the new code so it doesn’t clutter their screens. Source code control allows them to have a clean screen and simply revert an old commit rather than trying to remember what the working code was.

“Keeping track of who did what” is indeed a very useful feature of version control especially if the team is very large. I have seen in the company how easy it was for a developer to track a colleague who made a certain change he was interested in. They were able to discuss the problem, modify it together or even revert to the old code without inconveniencing the entire team. It is true that a lone programmer would not have this problem but there might be the case when you want to share your code with someone else. For example, I shared my code with my boss once to help me fix a bug. Later on I broke his code and was able to check the project history and see where the bugs were introduced or revert to his working version.

I agree with the fact that version control allows you to “expand your project in the future”. In my case version control enabled my boss and his team to continue working on my code after my departure. They can now experiment with new features without interfering with my working code. They can even maintain multiple versions of the developed software product and easily check the differences between them.

It is true that merging multiple changes to the same piece of code using version control “can be a pain and cause aggravation”, but it is better than one person doing all this by hand. I disagree that this is not the case in an individual project since merge conflicts between multiple branches can still happen even if you are the only developer. The best part of being a lone programmer is that you don’t have to over think the merge and it is less likely that you will have to solve the conflict manually.

Yes, familiarising yourself to the version control system is a ‘”point of stress”. Even though the company I worked for had the source code control set up it still took me some time to get used to it. If they didn’t have it set up I would have taken the time and done it on my own since version control does indeed make your life easier.

Conclusion

I think that version control should be used in any software development project irrespective of the team size. For the student working on his thesis project, using version control with an online repository will give him one less thing to worry about: losing or irreversibly breaking code. Moreover, you never know who you will need to share the code with or if it will be used in the future.

References

[1] Saikat Basu, “Not Just For Coders: Top Version Control Systems For Writers”, May 2013, “http://www.makeuseof.com/tag/not-just-for-coders-top-version-control-systems-for-writers/

Introduction

Continuous Integration (CI) is a Software Engineering practice that ensures the quality of a software product by running a build after every change of the code. Throughout the years CI has proved to be an essential software development technique. However, not all aspects of CI are relevant for every single software project. Moreover, some people misuse the CI concepts and end up failing to produce good results.

I have recently finished an Industrial Placement at a software design company. This article will present my thoughts on CI based on the experience I gained during my work within the company.

 

Background

CI is based on daily integration of work from all the members of a team. The aim is to detect errors as early as possible in the development process and fix the bugs immediately in order to reduce project time.

In his article [1], Fowler presents the following main concepts of CI:

• Singe source code repository
• Automated, self-testing and fast builds
• Daily commits to the mainline by all the team members but only after a successful build
• Replicate the production environment in order to test the code
• Make latest deliverables available to everyone
• Automate the deployment

 

Experience

Given the descriptions of CI many people might think that it is only worth applying it in projects with more than one team member. This is definitely not the case. The project I worked on within the company represented my master thesis. Therefore I was the only developer in the project and I was coding everything myself. Although it took me a while to get used to the company’s version control system (SVN) and their rules I soon realised how useful CI was. I really valued the security of having my code automatically built, tested and deployed. Moreover, by running it on another machine ensured that my code could be safely used and updated by other engineers after my departure.

Although I was assigned an individual project I was still a part of a bigger team which allowed me to understand how they use CI. I have seen that there is no right way to implement CI. In order for it to be successful, its practices have to be modelled with respect to each company, project and team. In his article [1], Fowler presents an optimistic approach to CI and does not talk about the problems that may arise. I will discuss some of these issues that I have observed during my placement.

The project must have some kind of infrastructure before applying CI. But what if the current project is being developed using an older project that didn’t use CI? Many companies (including the one I worked for) use legacy code when developing a new software product. This makes the process of achieving CI even longer and more unpredictable. The most effective solution is to use an incremental approach; start with less frequent builds and increase the frequency as everyone becomes more confident.

The larger the team, the increased overhead in maintaining a CI system. Because of the increased number of developers, the team I was a part of decided to have multiple component CI systems. The project tasks were split between several smaller teams who applied their own CI approach on their work. These sub-systems were used to build an overall system level CI which proved to be more efficient than if there was a single massive system from the beginning.

It is very important for the repository to contain everything necessary for a person to build anything. Test and install scripts, IDE configurations, documentation and many other things must be committed to the mainline especially if the code may be reused in the future. Also, artefacts from old builds can produce false results. Developers must clean the old artefacts before running a new build.

As I said, doing CI effectively involves frequent builds and commits from all the team members. Developers must commit every few hours so that bugs can be fixed quickly and the progress tracked efficiently. However, not all the members of a team have the same level of experience. Graduate students are hired throughout the year so it is very likely that they will end up working on a project that is already mature and applies CI. The solution is to provide systematic training and ensure that everyone has good test coding and build scripting skills.

The worst-case scenario is that people commit just before going out for lunch or before they leave work. This was proven to be a bad practice since it causes many integration errors. Frequent builds and commits throughout the day ensure that the bugs are found and fixed quickly.  This also helps increase the moral of the developers since they don’t need to delay lunch and can leave work when proposed.

It is important to differentiate between nightly and weekly scheduled builds and the integration builds. The scheduled builds are usually test builds that take a long time and run even if changes have not been committed. It is advised that developers do an integration build after every change to the mainline. This is because even if a build succeeds it does not mean that software product is working correctly. If later on a full integration build fails it will take longer to find and fix the bug.

Fowler says that builds must be fast but he is not talking about the quality of the final code. If developers rush into building and committing their work it is likely they will not meet the company’s coding standards. It is better if they take their time and make sure that they produce good quality code and save time later on refactoring.

Eric Minick makes a good point in his article [2] where he suggests that Fowler’s article is too focused on build. He says that Fowler should have expanded the scope of CI past build time by emphasising more on the importance of testing. Given my experience within a company I agree with Minick that tests are very important. Most of the employees were verification engineers and a wide variety of verification methods were used. A lot of time and effort was put into verifying the software product and bugs found from running tests were considered a great success. This is because finding bugs proves that the verification techniques are working effectively.

CI was very useful for this project since the customers intended to use the product to create their own. Using frequent integration and bug fixes, small releases could be made to the customers. This allowed them to start their own software projects earlier rather than wait for the final version. Moreover, if the project is late and the customers get impatient, build and bug reports can be sent to them. This way the company is able show the project’s progress and receive constructive feedback.

Communication between the teams working on the same project or between a team and the team leader is also a part of CI. The team I was part of had weekly meetings in which they were discussing the bug and build reports. The progress of each team, interactions between their work and the customer’s input and expectations were reviewed and examined.

 

Conclusion

Continuous Integration should be a part of each software development process irrespective to the subject of the project or the team size. Although it is a simple concept it is very easy to implement the CI concepts wrong and obtain poor results. Making the builds very fast or too frequent and committing the work at the end of the day are just a few of the bad practices of CI. However, if implemented correctly, CI is an essential part of a successful project.

 

References

[1] Martin Fowler, “Continuous Integration”, May 2006, accessed February 2014

[2] Eric Minick, “Continuous Integration: Was Fowler Wrong?”, July 2008, accessed February 2014