Listening to Micheal Jackson - Man in the mirror, just got me inspired. In this song, he's suggesting that making changes at scale must start with a willingness to look at ourselves in the mirror and take this opportunity to initiate changes at our end first.
I’m starting with the man in the mirror. I’m asking him to change his ways. And no message could have been any clearer. If you wanna make the world a better place. Take a look at yourself and then make a change.
While listening to the song, one can feel concerned and empowered to play a positive role in changing things. By using such expressive words, we tend to understand that if we start by changing our behavior, our habits, then by consequence, we will contribute to shape a better word, a better society, better projects, highly performing teams, healthier code...
It is sometime possible to hear someone laughing about someone else's code, or claiming out loud of being able to do better while depreciating a whole team. I would lie if I say that it is an attitude that I've never had. The outcome ?! Well, It's hard to deny how I regret that. I regret not having a chance to stare at myself in the mirror in such circumstances. I regret not asking whether it did already happen to me to produce glitchy code in the past, and imagine how I would have felt to be lecturing myself in such a negative way. Somehow, I would have felt terrible. And by odds, I wouldn't have accepted, in such situation, any lesson, any feedback nor any criticism even if that might had contributed to improve myself, and the code I would produce.
It is easy to say that a piece of code is badly written. It is easy to complain or even laugh. But the question is: are you good enough to make it better? - Sandro Mancuso "Software Craftsmanship"
With a step back, I would say that having such attitude is a rush to judgment and a lack of professionalism. Neither does it help improve a software, nor the project team or even the person making the blame. If a piece of code is badly written, then there is for sure an explanation to this. It doesn't mean by default, that the ones who did produce it, are a bunch of losers.
In general, when we take time to understand the reasons that led to such a state, we start getting comprehensive and able to change things. I remember running a code audit for a startup in Antwerp. The company was targeted by an external acquisition. I was involved, by one of the companies willing to make the deal, to lead a technical audit and check how healthy the solution was. I can say, right now, that if I had just limited the assessment to the code base, then the score would have been a 3/10. But wait, is the code base the only and main part to define how healthy a software solution is ?
In all, this startup, that was mainly building a solution written in Scala, Java along with a predictive AI module done in Python, was sold for more than 24 millions Euros. While running the audit, I felt an interest to understand surrounding context : how big the team was, the release notes, the staff turn-over, people seniority and market competition. All of these are key factors that might influence, at some point, the code base and the quality of a software.
Let me tell you about the story of Tom who just joined a new team. First day, he looked for the project's git repository, cloned it and there the game could start. He opened the project on Intellij, downloaded related dependencies, compiled everything with maven and surprise ! There was no surefire report. Obviously, he thought that there were no unit tests. He took a step back and spent some time going through the code. Then thought: "Maybe I did miss something...". He ended up finding 3 test classes in the "src/test/java" folder. He felt a little better about this, but once he opened the files, it was like falling from the seventh floor. All the tests were commented.
So, what would you do if you were Tom ? Let's start with the reactions that anyone must avoid:
- Curse: What the heck ? Why are the tests commented out ? Are you kidding guys ?!! I quit...
- Ignore: Do like you have seen nothing. Close the IDE and leave work at 4.
- Indulgence: Well, they probably had a good reason of doing this, the project isn't that easy and the scrum master doesn't look that concerned about this. So let's just leave it like this.
- Conspiracy: Hey Tony, did you comment the tests ?? You did well dude, it was blocking the build anyway !
It's easy to overreact, to behave without taking a step back. It's important to consider the consequences of our attitude and refrain the temptation to act in a way that might prevent other people willingness to make changes. An even more important aspect is to consider how we could start by ourselves to have a positive influence that would lead others by giving an example. If I were Tom, I would do the following:
- Communicate — Talk with the team, Tony for instance, and understand the test goals.
- Analyze — uncomment the tests, read the code and refactor until they pass.
- Verify — Verify that any change made isn't altering the code base integrity.
- Embed — Push my code through a pull request and involve a team-mate for a code review.
- Retrofit — Merge the active tests in the common branch (i.e develop).
- Normalize — Now that an example is made, and that the team has been involved, one can start to lead and normalize.
If you pay attention, you can notice the C.A.V.E.R.N acronym. It's a convenient way to illustrate how an unwise decision and attitude could be unproductive. Before judging someone else's code, it's important to understand the context, to discuss with stakeholders and get our hands on.
It might be convenient to start by giving an example and then try to normalize the approach rather than starting by blaming others. By willing to reconsider the way we act, it becomes natural to inspire others and delight them toward raising the bar and embracing craftsmanship.