Looking for technical excellence is a mistake

If today someone ask me what is the best software I have designed, I would answer that the next. Every time I look back I feel embarrassed about the software I implemented and this is precisely because I gain more experience and have more information to make better decisions. For this reason it is impossible to design a perfect software because while doing the code the design challenge changes or complements quality attributes that initially had not been considered and that even from the functional perspective had not been taken into account. The human process of problem solving is iterative, you learn by doing.

If it is not possible to have perfectly well designed software, ¿why do i spend time refactoring the built code to do it better? Or why do I spend valuable time making designs that are not going to be perfect? While it is not possible to have perfect software from the human ideal of beauty, it is not a secret that in time the complexity of the system increases making developers slower and affecting quality because the code becomes fragile, certain changes affect parts of the system that should not be affected generating a kind of butterfly effect and generating in the users and clients the sensation that the area of ​​technology is slow and everything that does fails. For this reason the software design should focus on the benefit and not on the perfection from the technical point of view.

We call the good design decisions features, the bad are called technical debt. A design is successful when it is used at the right time and place. Even obviously bad designs from the perspective of good practices can be correct designs for the organizational environment in which they are used and the business objectives that they help to achieve. Here is an example.

The company dreamers s.a. implements a medical appointments attention system that its intended to be selled to all independent doctors, hospitals and health care centers in Colombia and Latin America. This is the objective and based on this the business plan is established. Once the support of the investors is achieved, a development team is hired led by one of the best architects in the country with the aim of building a scalable and flexible system to support the evolution of the business.

In that lapse of time the company pragmatists s.a. observes the same market opportunity and hires its own development team whose objective is to develop the minimum viable product to validate its business model in the market in the fastest possible way.

The architecture of dreamers s.a. makes the system flexible to customizations, scalable to many users, use state-of-the-art technology and all the recommendations that come out on the internet to make cloud applications. On the other hand pragmatists s.a. implements a simple architecture with a web application and a database.

3 months later pragmatists s.a. has a first version of the product ready to be marketed, while dreamers s.a. only has a solid foundation of the software on which they will begin to build functionalities. 4 months after that dreamers s.a. releases its first impeccable version from the technical point of view.

Pragmatists s.a. has been marketing the product for 4 months, he has a large volume of clients and evidently gained ground to dreamers s.a. However, from the technical point of view they have problems, their systems are becoming slow and the customizations that the clients request are done by placing conditional statements in the code which makes it more and more complex and difficult to modify. This situation is becoming untenable, the business and technology leaders analyze the case and realize that it is necessary to rebuild the system because it no longer supports the level of users and the number of customizations requested.

From the business point of view pragmatists s.a. has a validated business model with real users and customers that allow financing the evolution of the product. Dreamers s.a. only has a good system based on assumptions that may never be true.

In the case of Pragmatists s.a. the design decisions were correct from the business point of view although incorrect from the technical point of view. In the case of dreamers s.a. Technical excellence was a rock in the shoe to achieve your business goals. What good is having a perfectly well designed software that does not create value?

I’m not meaning to say that technical excellence is not important, I’m saying that the most important thing is to support business objectives and evolve the architecture from concrete facts, from scenarios that allow building practical and useful code from our customers and users reality.

If our focus is business value and not technical excellence it will exists imperfect code, code that can be improved from the design point of view (And this will happen even when the focus is on technical excellence as the environments change and the software becomes obsolete). This is why it is important to build systems that can easily evolve in the face of environmental changes, instead of flexible and configurable systems with support for use scenarios that may never happen. It is better to have code easy to eliminate over excessively extensible code.

The technical debt is a reality (both the known and the one that we do not know yet) and therefore it should not be seen as something negative, because it is simply a factor that affects quality attributes, and as we know the importance of these varies according to the challenge of business. Not all quality attributes have the same importance in all systems and therefore technical debt must be managed by understanding what quality attributes affect and prioritize improvement efforts in paying off technical debt to generate a greater return on investment.

Traditionally we have used 2 tools to identify technical debt: static code analyzers (such as SonarQube, PMD, FindBug, etc.) and code reviews performed by peers or technical experts. Both tools are very effective to identify technical debt but not to manage it strategically for the following reason.

The static code analysis tools identify all aspects of the system that have design or implementation problems but do not identify which points of the system are generating real problems of quality or productivity in the developers. How many of us have felt overwhelmed when we do static code analysis with tools like SonarQube and observe that the technical debt is 10 or 15 years? It is absurd to even think about paying off all this technical debt. But how do I prioritize the one that has the greatest impact on the quality attributes important to my system?

The same goes for the code review, from the point of view of technical perfection there will always be many opportunities for improvement identified by an external observer, Even 2 different people can observe the code and find different design problems sometimes contradictory to each other. How to really know what I should correct to generate return on investment? As an observer in the code review how to identify the difference between a design or implementation problem that really has problems on quality attributes and those that are desirable?

Social code analysis adds a new perspective by combining information from the environment in which the software is used and developed with the information from the static code analysis and the findings found in the code review. Normally this information is scattered and rarely correlated to make better decisions:

Combining the information that is scattered in these tools we can:

These are just some examples of what I can achieve by doing social code analysis. In this way I can ensure that the technical debt that comes out has a direct return on investment to benefit the quality attributes of my system. Ignoring the one that due to current conditions does not need to be paid.

The technical design should be at the service of the business, even when benefiting it implies making certain incorrect decisions from the technical point of view. This does not imply the absence of a technological strategy to evolve the systems, it implies that that analyze the technical decisions from the point of view of the benefit created in the context, not from the perfection stated in the good practice. The technical debt must therefore be managed from the benefit created in the quality attributes when paying it off. From the business point of view there will always be 2 important quality attributes: The reliability seen as that the system does what it has to do at the time I need it and maintain the level of efficiency of my developers so that they can create value at a sustainable pace over time. Both quality attributes require focusing the management of technical debt in the correct points of the system to balance the generation of value in the short term with long-term sustainability.

Related posts:

For a better part of my coding career I have been missing this beautiful standard built in collection object. This has mostly been because node version 0.10 did not support it. Node kept updating and…

The ability of a system to calculate, reason, perceive relationships and analogies, learn from experience, store and retrieve information from memory, solve problems, comprehend complex ideas, use…

The dataset I chose is the affairs dataset that comes with Stats models. It was derived from a survey of women in 1974 by Red book magazine, in which married women were asked about their…