The Highly Standardized Code Syndrome

Dear reader, this article is about a theory under construction and it's been improved and nurtured over time by me. Your feedback is more than appreciated.

A little bit of history

There was a time when programming standards and good practices were created in silos. Big companies like IBM, Microsoft, Oracle, Sun and even NASA had their best practice manuals and some were kept as secret as they did with industrial secrets. As the practice of developing software became more common, not-so-large companies started to create their own software and the desire for standardization became increasingly evident, as is the goal of all industrial practices.

Over the years, the Software Engineering literature has established a series of standards and good practices that have taken software development to an industrial level. Design patterns, paradigms, principles, concepts and techniques were established over time so that the source code produced would have a more industrial and less personal character. Furthermore, introducing these best practices allows the source code to be better understood, better maintainable and at a lower cost for everyone, programmers and companies.

This level of maturity has allowed software development to become a reproducible discipline anywhere in the world, true engineering.

However, many of these standards have been thought, grounded, tested and established in silos. Real problems in real teams and companies that do not necessarily reproduce the scenario that a developer lives. In addition, these concepts are often mutually exclusive, when applying one of them you cannot apply the other.

As well as the lack of standards is a problem for the delivered source code, and the use of too many of these standards can be a problem as well. This is the fundamental ground where can establish the Highly Standardized Code Syndrome.

The Highly Standardized Code Syndrome occurs when a software engineer believes he needs to use as many design patterns, principles, concepts and techniques as possible from the existing literature or from the industry. Consequently, his code takes a long time to be produced and delivered and he strongly believes that this will guarantee the final quality of the code produced - Felix Coutinho 2021

In some ways the Highly Standardized Code Syndrome is comparable or I can say has its foundations in the historical article from Donald E. Knuth as you can see below.

"Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%." (The emphasis is mine)

Of course, the Highly Standardized Code Syndrome is about standards and not about optimization but they are quite related due to the nature of the intention of their use which is the outcome of the work. In both cases, it can fail a project or at least delay of the delivery.

Detecting the syndrome

The picture below can give you a clear sense of when the Highly Standardized Code Syndrome arises. The ascendance and the peak of the curve represent the first symptoms of the syndrome and the descending line demonstrated the awareness of the syndrome and the efforts to get healed from it.

Image by Flavio Copes via Twitter

Feedback first, optimization last

A good exercise for software developers, architects and engineers is finding the right balance when applying existing industry standards.

The simplest formula we can establish is problem, scenario and solution.

In other words, you should wait until you have a real problem sourced by feedback and then you can find a solution within your scenario. Otherwise, the result will be an excess of solutions to problems that you don't have at all which will very possibly result in the Highly Standardized Code Syndrome. The developer will have spent a lot of time on problems that he doesn't have.

And in general, finding the right balance between standardization and flexibility is important for a successful software development project.

[Changelog]
6th version on Feb 9th, 2023
5th version on Feb 8th, 2022
4th version on Feb 1st, 2022
3rd version on Aug 21th, 2021
2nd version on Jul 21st, 2021
1st version on May 13th, 2021