When Software Talks


It begins as a feeling in the abdomen, something that gnaws and feels quite uncomfortable. They did not know how right they were, Martin Fowler and Kent Beck who coined the phrase code smell or perhaps they did.
Well, I have identified some place in the code that gnaws and smells and begin to refactor. Sometimes the refactoring is easy and quick. Sometimes there are so many nested dependencies so there is no simple way to refactor. There is a refactoring method called Mikado I have started to use which is a structured way to unravel and refactor tangled dependencies. If my employer lets me be and I continue to follow my intuition, then things starts to happen. For me, refactoring is a way to get to know the code and make it mine. And finally the code starts to talk. It is a deeply creative process that is very satisfying and personal.
In my earlier life I took a course in film studies and wrote an essay on the film Metropolis and then the same thing happened. It can also happen when I am studying a music piece with my choir, Boo Cantabile. The score on the paper begins to talk, or rather sing. When I lay a jigsaw puzzle the same thing happens. In the beginning everything is chaos. Gradually, you can begin to see patterns and sort the pieces by some system. Then subdivisions appears and at a certain point the puzzle begins to talk and more or less resolves itself. Programming is a craft more than anything else.
Unfortunately there is seldom understanding of this creative process among principals, project managers and product owners. There is such a focus on the short-term; delivering functionality for the next sprint or a deadline. This incurs technical debt and is difficult to avoid. The heroes of salable functionality is software development’s response to quarterly capitalism. I have been and remain a strong proponent of agile development, but also see the risk of “short-termism”. How can that come to be and how should you respond?
Sometimes a development team is under the pressure of deadlines and can not muster the strength to dive deep into the code, but are forced to continued accumulation of technical debt. I know what should be done and it would be beneficial to the client in the long term, but I cannot do anything about it. It’s similar to when you’re stressed and are forced to breath with your chest instead of breathing with your stomach, a breathing that is better except in extreme emergencies.
Often the pressure is from the developers themselves as Henrik Kniberg so aptly expresses. We are an impatient species and often the press is a chimera. But sometimes the ignorance simply is due to lack of competence of those in charge. They do not know what separates good from bad software and has no understanding of what technical debt means. It requires skilled programmers which can also spread their insights to the entire team. A good leader has either the knowledge or has sufficient trust in the developers in the team and let them spend their time as they choose. On the occasions when I have seen really good software been created or created it myself it has unfortunately often been thanks to some ingenious programmers “flying under the radar” and programs secretly without the management knowing. Why is it that? It’s something that at best is appreciated in retrospect but rarely rewarded while it is happening.
And this is one of the truly great risks of agile development. It is easy to sub-optimize. Or is it something that affects immature organizations? Agile development is, in many respects, a powerful tool that perhaps too many embrace uncritically and throw the baby out with the bathwater.

One Comment

  1. I happened to find this article when I googled a bit on Java and quality and you have some interesting points in what you say and just what I have realized in my job as a Java developer, for instance to make use of refactoring as a way to learn code. There is no better way to learn the new code than to clean it up with small refactorings while I understand more and more of what it does and usually I have reduced the amount of code significantly also when I feel done but without changing the functionality. It can have a dramatic effect on the code quality in depth. Unfortunately, I feel, however, just as you also say that the skills of those who make the decisions are flawed. Specifically, I find that many people have a lack of understanding of what quality is. For many, it means high test coverage but it may even be a counterproductive measure sometimes! But the skills are too low for developers as well. The object-oriented paradigm is very different than procedural or sequential program flow, and unfortunately, I often see code where it is clear that it is written with a sequential mindset. It tends not to be so good. To become a good craftsman as it is called in the world of software development requires a lot of learning and I like to say now and then that our customers should begin to demand a discount on e.g. 30% of Java developers who are not certified. The certifications are of course a crude measure but it would at least increase the incentive to learn significantly among developers and their employers, and it is not unusual to see code where it appears that the developer has had a lack of knowledge about the syntax too. In any case, there is a need for many more who preach the importance of real quality in software development and therefore it is good that there are these kinds of articles that appear when googling for quality.

Comments are closed.