English | EN Keep Refactoring
Oct 9, 2017
One of my developer heroes, Bill Atkinson, once said “-If you want to get it smooth, you’ve got to rewrite it from scratch at least five times” and when a manager forced him to fill out productivity reports with the number of lines written in a week when he had made the QuickDraw’s region calculation routines to be six times faster and 2000 lines shorter, he put “-2000” in the report.
There are many lessons to learn from Bill, and one is that you should not get stuck on a chosen technical solution just because it happened to be the first one you found. On the contrary, as you understand the problem more over time, you can find more effective solutions. Another lesson is that the size of the code is seldom a measure of either performance or quality, again, on the contrary, the more code, the slower and the more possibilities of bugs.
I would even go so far to say that everything decay over time, and especially software. As most things, like operating systems, evolve, the software that run on top of them will need to change as well. Therefore, any software that is not updated to better adapt to the new environment in which it runs, will generate a technical debt. It’s not just about programmers taking shortcuts when doing the implementation, but simply about everything changing over time, which require a constant need for refactoring.
The same is true for most things related to a cross-funtional and autonomous team building digital solutions. The way the team works and the tools they use will need to change over time. When the team find a way of working or a tool that works, they will use it, but as soon as there is a better way, the team should refactor the way they work or the tools they use.
My experience as an architects is that teams and individuals that learn not to get stuck on how things are, and instead focus on how things should be with the current circumstances, will win. They know that in change there is always an opportunity for improvement, and they will never stop questioning if there is a better way.
Many of my fellow architects share similar experiences, and that is why we agreed on the following general principle:
We know that we constantly have to refactor both the
way we think, work, and interact as well as the
architecture, technical solutions, and code.
It’s something we strongly support and promote, and therefore it has been included in our Architecture Manifesto.
It’s also reflected in one the of the core values of the manifesto:
Focus and refactoring over detailed architectural design
I already covered the other part of that value in Focus on the Customer.
About the author
