Not long ago, I published “The Coder Habits: Los 39 Hábitos del Programador Profesional”, a book I made with a lot of enthusiasm and following more or less my own workflow for writing it.
This workflow basically consists of:
- Microtasks added to Wunderlist.
- Topic selection.
- Content creation.
- Review of the content.
- Research and reading of documentation.
- Checking what other professionals think.
- etc.
And, of course, several rounds of review and correction, all of this over several months, during which I perhaps had free half an hour one afternoon for the new book, two hours on a Saturday, and so on.
The curious thing is that in each of those review passes, I always found some detail to improve: a paragraph that was too dense and needed to be lightened with more agile and simpler expressions, a punctuation error that made me use the RAE more than I would like, a new nuance, or the correction of repeated concepts in a section.
Not long ago, I was discussing this with a colleague and I said that it is difficult to determine when you consider a book to be “ready” and when you can declare the work finished for publication, because with every review you always find something you would like to improve, or something that sounded very good before but no longer does.
By the way, I recommend doing a read-aloud as part of the review process, because it helps reveal expressions with an odd sound.
Therefore, we reach the conclusion that a book is never “completely finished.” It may reach a point of maturity where you believe it is ready to be presented professionally and with quality, but it makes you think that if you review it ten more times, fifteen or twenty more times, the book will necessarily change in many aspects. It is common for authors to revisit their own works years later after publication (even more so if they have had some success).
It is difficult to consider a book finished. And exactly the same happens in a software project.
Every time I review one of the projects I have worked on, I always find some small detail I want to improve: perhaps a design improvement, or I find a secluded place where a small refactoring could be applied, or I think of extracting those helper classes into an independent library, or I want to take advantage of a new feature from the latest update of the framework I use.
Leaving aside the fact that the project may be asked for new requirements and functionalities, I would not be able to categorically say that a software project is already finished “completely”; it works, its tests pass, it perfectly meets the client’s needs, so wonderful, it is ready for production, but we will always find things to improve, no doubt about it, both in the quality of the code, its design, and the quality of its tests.
Therefore, it is difficult to claim that there is such a thing as “perfect” software; it may be perfect from the point of view of its operation, but there will always be something to improve in a project with thousands or hundreds of thousands of lines of code.
However, improving and changing just for the sake of it also makes no sense. I always ask myself what this new change I deem necessary contributes: if it simplifies things, makes the code more elegant, readable, easy to maintain and reusable, then it is a necessary change; but if it does nothing of the sort and only makes things more complicated, it is better to leave everything as it was. I remember that many years ago I changed things without asking whether I was making the design more complex or obscuring the solution a bit; now I always change something thinking about simplification.
Changing just for the sake of changing can also be dangerous if the project is not sufficiently backed by tests; if it is not, it is better to focus on having a quality set of tests and then we can dedicate ourselves to improving whatever we want.
Before starting a new development cycle, I always try to spend some time improving aspects of the previous cycle that may not have turned out too well or resolving that pending technical debt; this is also a way of preparing the ground for the new functionality that is to be incorporated.
Given that, I do not understand how a developer can ever get bored, because even if everything works perfectly, there is always something to optimize and improve.
I believe in continuous and iterative improvement; I trust more in building something of quality little by little, not in bursts (a lot today and nothing next week). Try making five small improvements that take ten minutes each over the course of a month. What will happen once you have accumulated hundreds of micro-improvements in your project?
It is no coincidence that one of the longest-lived projects I am responsible for right now (a digital meter management platform), even after seven years and several versions, and after being deployed to many clients, from time to time we still find a small bug.