Our team is reading through the classic Clean Code together. After reading a chapter or two we will get together to discuss the concepts over lunch. We try to keep them fun and interactive. These are the slides from our first session (link).
In discussing the question – why don’t we write clean code – we explored the following three reasons.
There is a level of subjectivity
There is a good chance that when I opened a pull request for my team to evaluate, I thought the code being pushed read like well written prose, was understandable to others, tested, and was thus maintainable by my colleagues. However, the code should be considered readable by the team that is responsible for owning and maintaining it. Which usually means that there will be some comments and feedback.
There may not be an understanding of what Clean Code is
If writing clean code was obvious I imagine that Bob Marin would not have written a book on it. And sites , like the Daily WTF, poking fun at various “dirty” code would not exist. Understanding what clean code looks like and the techniques to improve it must be learned. Our goal as a team is to work through Clean Code so everyone on the team will know what clean code is and why it is important.
There was a deadline to meet so there wasn’t any time
Perhaps the most common excuse for why “dirty” code is accepted and deployed is because the team rushed to put something together to meet a deadline. Unfortunately, that means that we now have to make time to not only add new features, but also go back and clean up the mess we made.
Bob Martin pushes back on the deadline excuse, noting:
The only way to make the deadline – the only way to go fast – is to keep the code as clean as possible at all times.
Quality is not a product variable
When I was exposed to Agile one of the notions that stuck with me was something similar to the Iron Triangle presented in this article (link). The idea was that the product owner and stakeholders would be presented with the project variables (scope, schedule, and resources). After flushing these out they would be asked to identify which of these variables is fixed, which is firm, and which is flexible. The caveat is that each of these can values can only be used once.
When marking the variable that is fixed the stakeholders are identifying the part of the product that cannot be changed in order to provide value. Maybe the scope (features) is fixed because the capabilities defined already were scaled back so that the minimum viable product (MVP) was being built.
The next variable is marked as firm. The variable identified in this manner is one that the stakeholders can give on here and there and still achieve value. For example if the scope was considered fixed, then the schedule that was proposed might be able to change depending on how the project moved forward.
The last variable is considered flexible. This is where the stakeholders have the most ability to change things so that the other two variables can be met. In this example, the resources (servers, teams, support, training) are where the stakeholders can invest the most to meet the scope and schedule.
This technique has proven helpful in shaping expectations on a project. Though it is important to continually evaluate these variables along the way. What really stuck with me was this. When the instructor explained this concept, he wisely noted that one variable was left off the chart. This was because is was non-negotiable. That was code quality.
The Agile Jedi 