Today, I’m going to write about quality in programming. Of course, there are many levels at which you should contribute real value to the project development — starting from implementation, automatic testing, and team cooperation, ending with essential communication with a business branch. Yet, right now, I’m going to focus primarily on the quality of the code itself and the different perspectives it presents.
Providing code excellence
There are plenty of factors that influence the character of the code in your project. For instance, the list includes mindful decisions, sound design, code readability, static code analysis and typing, code review, automatic testing, documentation, development experience, automation, availability, and scalability of services. Those are only some of them that you can think about. It is safe to claim that the more quality indicators you incorporate, the better is your code. Reliable repository and code condition improve engagement and satisfaction for those working within. In addition, they allow better team cooperation and optimizing the development time, which is crucial for business.
However, there is a catch. From the pragmatic point of view, you may not need most of those features and still do fine work, but first, let’s talk about a predictable code.
Predictability
Knowing what represents and ensures code quality, you should understand how it may change and what it affects. In short, the better the code, the faster you can assume how it works, and the easier you can estimate the effort required to modify it. The system in good condition behaves as desired and evolves steadily and expectedly. This predictability is probably the most significant trait that you can rely on and build upon.
Now, we can compare two projects, one that is of high quality and another not so much. The first one uses different factors to assure its high quality, and the second one does not.
When projects in question are small, and you are asked to introduce some modification, the cost in the first project, despite the better condition, is higher than it is in the second one. That is because you need to satisfy quality factors alongside the implementation, and without a doubt, that takes time.
When the design grows in complexity, the cost of introducing a change in the first project may still be higher, but the gap surely narrows as the second project becomes more troublesome. That happens because more extensive and complex codebases tend to introduce problems that affect present operation as well as future modification. When your ability to understand the issue is crippled, due to worse condition, you waste some of your time.
There is a point where changes in the first project become cheaper than changes in the second one. Of course, the cost grows from the point when the design was smaller, but the increase in the first is steady and easy to measure. On the other hand, the second project at a certain level of complexity becomes so unpredictable that the modification cost explodes. It may snowball so that at some point, it may be cheaper to rewrite everything than to try to modify the current codebase. That is because problems residing in different parts of the application may appear unexpectedly and require immediate attention and fixes.
That comparison of good and bad codebases showcases the great importance of the system’s predictability and its effect on the cost of maintenance and development.
The system is too complex
All of that helps to understand that there are many quality features and different situations for programmers to consider. Probably, the most common scenario is that you have a project that starts small and does not need a lot of maintenance. Nevertheless, when the system grows, sooner or later it will reach a certain point where it is more optimal to keep it in good condition and employ solutions to provide high code quality. It is not always the best idea to accommodate everything at once. Do it gradually, remember to take a moment and think about developer experiences you can improve, re-evaluate your code and utilities as time goes by.
As I stated before, a codebase with fewer quality elements may be cheap at first. Still, when you consider the predictable development time in the future, you will recognize that, at some point, it is better to invest a little before gaining enormous profits later.
The system is too pricey
On the other hand, sometimes, you do not need good design, static analysis, tests, documentation, or automation. You may even not need any code review whatsoever. Sometimes, you create a small, separated, short-living piece or a proof-of-concept, and any additional overhead would be truly unnecessary. That may sound like a concrete example, but it is common to start a small project with a plethora of supporting utilities and later dump the code because it is too expensive to reach a certain goal, and time is depleting.
The smaller the code, the fewer developers, the shorter it lives, then probably the less ensured quality you need in it. Think about features that solve specific problems or automate specific tasks and remember that those elements always come with a cost.
Pragmatic decisions
To summarize the topic, I would like to repeat one thing: code quality aligns with its predictability, and that alone is a fundamental trait. You should remember that with growing complexity, it may be your best ally to control the code. However, it is due to the programmer to decide how much it is worth investing in maintaining that. Be pragmatic!