How to Create 10x More Maintainable Code

“Technical debt” is our means to measure how maintainable our software projects are. Others will strongly disagree with me here, but there’s no room for disagreeing. We already have tons of science in the subject, and technical debt grows on average proportional to the number of lines of code your solution contains. This implies that less lines of code equals a higher degree of maintainability.

The reason for this is because our brain can only keep a certain amount of complexity in its conscious parts at once. When you increase LOC count, and start separating your concepts into multiple files, the size of what you need to put into your head to understand the “whole” grows. And as it grows, it becomes mentally impossible for us to keep track of everything at once.

Separation of Concerns

Even though we try our best to separate our code, such that each file only contains one “concern”, the end result becomes we need to touch upon 4 or 5 files to edit a simple CRUD read endpoint. To illustrate the case, realise that this Hyperlambda code ...

http.get:"https://api.somewhere.io/api"
   convert:true
   headers
      Authorization:Bearer BEARER_TOKEN_HERE
data.connect:crm
   for-each:x:@http.get/*
      data.create
         table:contacts
         values
            name:x:@.dp/#/*/name
            email:x:@.dp/#/*/email        

… needs 8 files and 87 lines of code in its C# solution. Hyperlambda 11 lines of code in one file. C# 87 lines of code in 8 files. Watch the following video to understand why that is a problem.

Facts are, if you’re an average software developer, you’re probably separating your concerns wrong. Yes we should separate our concerns, but separating your “service implementation” from your “persistence layer” is overkill 99% of the time. Separating your concerns in a healthy and clean way, implies having all the code related to one aspect of your app in one file, and all code related to some other aspects in another file.

Need to send an email? Cool, one file, not 8 as is demanded by our “best practices”. That way when you’ve got a bug in your code, or you need to modify it to add another feature, you can see all code related to the issue at hand in one file. This allows you to “upload” one concern into your brain as you start maintaining your code, and keep the entire context required to understand the code as you are maintaining the code. This is such a self evident fact it puzzles me that devs are still arguing …

Other software developers will violently disagree with me here, but even if 30 million people are telling you lies that they read about in some 30 year old book, accepted as “dogma” by the industry, their lies are still lies.

The belief in SoC is the worst thing that’s happened to our industry for the least 30 years

And the reasons for that is because most of us aren’t building Facebook or Twitter, we’re creating business administration apps, as enterprise software developers, and the statistical probability of that we’ll at some point “change database” is roughly equal to 0. However, by “anticipating that need”, and creating YALOA (Yet Another Layer Of Abstraction) using OOP mechanisms, instead of making the code more easily maintained, the result becomes the exact opposite.

If you create code that’s 10% of your current codebase, the resource requirements to maintain that code drops by 90%. This implies that you should always strive for creating less verbose code. 10x as much code, equals 10x as much technical debt.

To see how we’re dealing with complexity, you can check out Magic Cloudhere, or visit our company website here.