Why Complex Systems Don't Always Equate To Effective Software

There is a misconception that the number of lines or the complexity of code determines the completeness or quality of a system. However, writing code is like writing a novel -  the number of pages doesn't always indicate the quality, style or a cohesive storyline.

In reality, a complex system is often indicative of a flaky system - something that no one wants, especially in the long term.

Software complexity is often the result of legacies, outdated best practices, cowboy developers or a combination of these things. Complexity has more point of failures, exposing more surface area for vulnerabilities and it also puts pressure on those that inherit the system.

Complexity is not a good practice, even though for many it is a state of normality.

Units of Measurement

Under normal circumstances, the productivity of a team is measured based on output. In the physical world, factory workers are measured on the number of items they're able to produce against the hour, a courier drivers' productivity on the number of packages they're able to deliver in a day, and how many orders a fast-food chain can deliver during rush hour.

These are all valid metrics and therefore it may appear that the most seemingly obvious unit of measurement for software is the number of lines produced. But code is much more complicated and less mechanical for traditional methods of productivity measurements to apply. Quality is not synonymous with speed and quantity is not synonymous with the robustness of the final product produced.

So How Do We Measure the Quality of Code?

There is also a misconception that complex systems equate to a good system. However, complex systems are often the precursor to code that's failed to capture your business requirements in an effective, efficient and succinct manner. Code is the act of capturing what your business is trying to achieve and transforming it into a medium that allows for transactions to occur.

Code is the representation and interface between the business and the end-user. If this representation is unnecessarily complicated, then it's not setting your business up for efficiency or the ability to increase your output and pivot velocities.

Therefore, quality code is the software's ability to balance between delivering what the business needs promptly and remain sturdy in terms of code succinctness and overall cohesion.

Rather than the number of lines or the complexity of the code, what should be looked at is how the software satisfies the needs of the business and its capacity to do so in a manner that doesn't overtly frustrate the developer working on the code. Contingent bugs become easier to detect and dealt with - something that complex systems won't allow developers to quickly do.

What Does Quality Code Look Like to a Non-Coder?

It's hard for non-coders to judge the true value and quality of the software being delivered. In part, this is because looking at code is not their domain of expertise.

However, certain language markers communicated by developers are often signifiers of overall code quality. When a developer tells you that the system is complex, what they're saying is that there are a lot, and often too many, points of consideration and potential exposures to failure based on how it's set up and configured.

When a developer tells you that tasks cannot be automated, what they're telling you is that there is too much complexity involved and there are simply too many contingencies. The task of automation will often take more time than to address the issue at the source through a re-write. It often lacks standardization on a code level and fails to capture patterns on a niche and industry level.

What 'Complex' Can Also Mean

The word 'complex' can also be a code word for an over-engineered system. What this means is that the designers, system architects, and developers have designed too many and mostly unnecessary parts into the system to a point where it slows down future deliveries.

Over-engineering often materializes in the form of junk code and branches of features that are so interlinked in a way that cutting out one part has the potential to break the rest of the system. The process of its creation was governed by the thought of future flexibility and features rather than designing to the actual needs of the business.

While the idea of flexibility sounds great, being too flexible can result in a system that has no clear structure or backbone to work against. It becomes like water - you can't easily hold it or do anything in particular with the system that won't somehow break it.

Final Words

The quality of code is hard to measure for managers and those who are not directly involved with the code itself. The number of lines and output should not be the main focus.

There is an emphasis on clean and succinct code in the development community for a reason. In part, it's because the flakiness of complex systems proves to be highly ineffective and detrimental to the business.

So never judge the quality of software based on the number lines. Instead, look at the current speed of the overall feature delivery against past deployments. If the trend is consistent and without major frustrations, then your software is most likely in a good state.

If the trend is slowing down with more complaints, then perhaps it's time to pause and assess where the quality and scalability of your software is at, and what can be done to fix the issues before they become major cracks for your business.

Co-authored by:

Dave Wesley ~ President, SRG
LinkedIn

Aphinya Dechalert ~ Marketing Communications, SRG
LinkedIn