The Highly Standardized Code Syndrome
Photo by AltumCode on Unsplash

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 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.

No alt text provided for this image
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 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

This article was originally published by me on my personal blog at https://dev.to/felixcoutinho/highly-standardized-code-syndrome-54c9

Stéphane Mader

Senior-PM(NeoLoad)@Tricentis - Associate@TimeForThePlanet

12 个月

Three ideas/reactions come in mind 1. Whether it be design patterns, concepts or techniques, they all become dangerous when they prevent us from actually thinking... They're extremely useful to learn and spot similarities or analogies with the current problem you are facing but become lethal when you take them for granted. Their "ready-to-use" easiness ("prêt-à-penser" would say the French) kills them and the only thing you're left with is a very questionable justification lying in the fact that you can say I've used a "standard" way of addressing the problem. If you think of all the innovative ideas they're all a mix of patterns added to new ways of applying them to the actual problem (thinking of backends-for-front-ends used by Netflix for example and going from Groovy to federated GraphQL).

回复

要查看或添加评论,请登录

Felix Coutinho的更多文章

  • Mentorship is a Marathon

    Mentorship is a Marathon

    TL;DR: Mentorship is a long-term journey, not a quick fix. There’s a common misconception that getting a mentorship can…

    4 条评论
  • Designing cloud-native microservices [Talk][Deck/References/Links]

    Designing cloud-native microservices [Talk][Deck/References/Links]

    Hello fellow developers and architects! As we venture into the world of cloud-native microservices, I have compiled a…

  • You should stop using Spring @Autowired

    You should stop using Spring @Autowired

    Or "Why you shouldn't use Field Injection when using Spring". TL;DR Injecting beans directly into fields using…

    27 条评论
  • Lombok: The Good, The Bad, and The Controversial

    Lombok: The Good, The Bad, and The Controversial

    Lombok: The Good, The Bad, and The Controversial Java developers, particularly those coming from other programming…

    4 条评论
  • Creating Effective Code using Java Records

    Creating Effective Code using Java Records

    Java Records is a new feature introduced in Java 14 to make it easier for developers to create immutable classes. A…

    1 条评论

社区洞察

其他会员也浏览了