In the programmers’ career, there’s always a critical time during a project development in which they will inevitably ask themselves: “Should I invest my time in continuing to improve the code that is already ‘ready’ or should I just finish the project?”. It’s then that programmers find themselves for the first time in this paradoxical situation. The balance between improving what they have and implementing new things seems to be broken, and it’s time to make a decision.
Over the years, and with the experience that comes with them, a fast solution to this situation can be found. But for novice programmers, this may be a difficult decision, since finishing the project involves completing a powerful goal, and it can’t be denied that refining the code that is already done has an almost irresistible charm.
Is This Really a Paradox?
Although having to choose between continuing with the project or continuing improving the code may seem paradoxical, the truth is that both options are part of the processes of the software development life cycle.
When one addresses a project, whether a personal project or a client’s project, it’s normal, during its development, to notice things that one can improve. Every line of code that is written contributes to your experience, and this same experience will allow you to improve your code. For this reason, whenever one finds new techniques or resources, it is inevitable to wish to do a little bit of backtracking to improve portions of the code that can benefit from these new discoveries.
In programming jargon, this action is known as “refactoring,” and it’s a very powerful resource used by programmers to achieve significant improvements both in performance and data handling, being able to maintain the external behavior of the functionality that is being modified.
So, Where Is the Problem?
As it was mentioned, both paths are necessary when addressing a project. The project must be finished, that’s the main goal. But, at the same time, improving the code using new resources and techniques that are discovered also causes that the final project has a better performance. If both points are necessary, where does the real problem start? The problem can be summarized in a single word: time.d
The vast majority of projects (if not all) are managed using deadlines for their delivery/sample. Working within these deadlines limits the time we have to spend in each functionality. Taking this into account, it’s the programmers team’s responsibility to define each functionality to be developed and estimate the development time, to be able to provide this information in other project teams (marketing, design, etc.)
It’s then that this “paradox” arises. The programmer, during a functionality development, will have to decide what to invest their time in.
The Answer May Be Simple
Having reviewed the above aspects, the answer may be simple. The programmer’s priority is to finish the project and that it has the expected (or better!) behavior. The latter is what makes the programmer want to go over the code again and again to improve every little detail. But there’s a question that can save us hours during our reviews:
Is This Improvement for Users or for Myself?
As a programmer, one becomes “overprotective” with one’s own code. We all want our code to look nice and that, at first sight, it’s clear what it does. We also want to use the most professional techniques and resources we know. But, are all those changes really going to improve the user experience?
Often, we forget that what we are programming, generally, is intended to meet other people’s needs. This makes us think about improvements that will ultimately not benefit the end user. It’s useless to improve the functioning of the user experience (UX) if the user expects an improvement in the server response times. Similarly, there are performance improvements that end up being absurd. What is the use of changing a search method if the final result will be barely noticed by the end user?
With this simple question, it’s much easier to assess if it is worth investing time in improving the code you wrote last week or continuing with all the new things you still have to do.
Delivering a product with the best possible quality and seeing clients/users satisfied with the work done is the ideal situation when finishing the project development. While continuously postponing delivery dates due to the constant review and improvement of the code can end up being counter-productive in the relationship with your clients/users. In addition, you’ll always be able to use those new techniques and resources the next time!