Why good developers write bad code: the Agile perspective
What are the factors that can influence team members and their coding abilities? How can an agile framework breakdown in terms of produced software quality? We investigate academic literature to find the results.
It is without a doubt that every developer at some point has encountered someone’s bad code (or their own). While there may be a plethora of reasons for this, we wanted to look a little deeper into what reasons are linked to the employment of an Agile philosophy in the workplace.
A Canadian research duo have published a study of an in-house software development project within a large telecommunications company, which was under observation for a time period of ten months. The observation was conducted during mandatory weekly status meetings, where technical and managerial issues were raised and discussed.
The paper describes “cases depicting the complexity of organisational factors” and documents up to ten issues that have had a negative impact on software quality. The project structure in question was loosely based on a Waterfall model, however parallels to strictly Agile teams have also been made.
Problems of outside influence
Researchers Mathieu Lavallée and Pierre N. Robillard from the Polytechnique Montréal in Canada believe that their study answers the need for “more empirical data through the presentation of observed cases describing how some organisational factors can impact software quality”. Their work fills a gap academic research has seemingly ignored in the past.
While looking at a two-year project that was being undertaken for an internal client at the company, Lavallée and Robillard were able to report on several observed issues that related directly to outside influence on the team. Some of these issues were due to the distributed nature of the existing software being worked on, such as internal dependencies on different frameworks to support legacy code.
Other issues, such as organisation politics, come about due to managers and developers obtaining better results by calling in favours from outside the software engineering process. This means that newer members of the team, or novice programmers, aren’t able to tap into the outside influences that are “helping” the project:
For example, sometimes third party entities would refuse a CR on the basis that the change would violate the core functionality of their libraries. Inexperienced developers or managers would often accept these refusals at face value. However, employees with experience on the capability of the external libraries would often challenge these decisions… talking to the right person at the third party entity was the key factor of success.
Lavallée and Robillard note that this kind of behaviour is often deeply rooted within the organisational culture of a company. This is also the case when excessive pressure from managers and senior developers is present, who give direct orders and make threats to the team. The issuers of these orders may not have all relevant information to hand when making their demands, resulting in ill-defined priorities. “Bypassing the normal team structure undermines its decision-making process”.
Agile in a non-Agile environment
Ian Allison of the University of West Scotland presented a multi-case analysis study on organisational factors shaping software process improvement in 2010. He observed two crucial problems to the production of quality software:
- When a conflict arose between Agile teams within a non-Agile organisation, the will of the organisation prevailed and the Agile principles more or less disappeared
- Constant pressure from an organisation on one of its development teams forced them to change their practices, despite significant resistance on the team’s part
The trickle-down effect of such observations corresponds to the influence of the company on the team being larger than the influence of the team on the company. As Lavallée and Robillard state, “it can therefore be surmised that organisational factors may impact product quality, as the values of the organisation will influence how team decisions are made”.
The Canadian duo summarise their study by noting that while these issues might not affect project success, their own observations show that they do affect software quality, and with that, maintenance costs:
If the Module developed in this project is successfully deployed, it will likely be used for decades to come. The design flaws introduced because of the organizational issues presented here will no doubt come back to haunt at least a generation of developers to come, as the code written today will be tomorrow’s legacy code. Is this the kind of legacy we want to leave for future software developers?
Michael James, who wrote about co-workers writing bad code, agrees that this kind of practice is counter-productive and that bad code is everyone’s problem. “By the time I learned to program in the 1970s, it was already well established that the cost of maintaining software is far greater than the initial cost of writing it. This problem has only gotten worse as software has grown more complex”.
As a fan and teacher of Scrum, James consents to the fact that bad code can also flow from developers saying that they’re “doing Scrum”. He has even heard it cited as a reason to write bad code. He believes that pair programming, Test Driven Development (TDD) and merciless refactoring are just some of the ways that bad code can be weaselled out.
The issues cited above are not new in the Agile world, let alone programming in general. However they do highlight the ways that Agile processes can be manipulated and misunderstood, which results in poor quality work. Do you agree? Let us know in the comments below.