What makes a $2,000 development project different from a $40K one?
The $2,000 project incurs the so-called “technical debt”. A messy, spaghetti-like codebase is 5x, 10x, 20x more complicated to maintain, which skyrockets the maintenance costs over time.
Technical debt is a well-known phenomenon in tech. But due to the price cuts, it happens all the time.
The chart below shows the result of a survey conducted by CodeAhoy among software developers. Accordingly, the majority of the respondents are swamped with projects that have technical debt.
You are familiar with the business outcome, but here’s the actual explanation of what technical debt actually is and how engineering managers assess code quality.
What Does Technical Debt Actually Mean?
A term originally coined by Ward Cunningham, technical debt is the consequence of immature code work resulting in technical issues that may worsen if not resolved or “paid” as quickly and surely as possible.
Software engineers, especially those who are working on service-based projects and the like, often use the term technical debt to describe inefficiency in the codebase for software quality foundation and other things that are actually preventing us from building on top of an existing codebase.
There is a pretty fine balance between being able to provide a usable piece of software quickly for the rest of the public and actually building something that scales over time.
There are different ways to get this problem solved one way or another. Some incur technical debt by building a very cheap poorly-built Minimum Viable Product, simply in order to launch something for the market and then paying for a very expensive migration to something that’s properly built.
Some do include paying a very tiny sum of money for an initial build and then incrementally increasing maintenance and support costs over time simply because the initial code quality is extremely mediocre. So, you’re basically paying that with a very high interest rate over time. And of course, some do invest a lot more in the initial build only to be able to provide something that is easily scalable and grows over time.
There was a time when I spent a month with dozens of sales negotiations and different types of partnership meetings, client meetings, growth meetings, and planning for the year ahead. And of course, estimates and different types of pricing discussions were some of the most important things throughout the conversations because pricing matters.
In every instance, one of the things that are brought up the most are the following questions:
- Do you want it to happen fast?
- Do you want it to happen cheap at first?
- Or, do you want to save money over a period of several years?
Some of the sales leaders I’ve been following over the years transition this conversation between the cost and the rate or the price of a specific product. The price is actually the lump sum that you’re paying at once and the cost is the ongoing fees, and support and maintenance, and everything else that is happening throughout the period of this project.
Having a product that is poorly built can be unstable, unable to grow over time, and can keep you limited. You are paying more to just sustain the lifestyle of this specific product instead of investing in business growth which, of course, is a critical problem.
Types of Technical Debt
In the same survey conducted by CodeAhoy, the respondents have enumerated the different types of technical debt that they could find in their projects.
Some of the different types of technical debt that they have identified are shown below:
Note that these are not set in stone. There are claims by different thought leaders that not all technical debts are disadvantageous.
Steve McConnell, for instance, suggested that technical debt can be intentional or unintentional. In cases wherein they are intentional, that is when teams use this as a strategic tool.
Martin Fowler categorizes later on technical debt into two major categories:
- First, the intent: Is it deliberate or inadvertent?
- Second, the context: Is it reckless or prudent?
He then proceeded to illustrate how decisions are made with regard to technical debt by using the technical debt quadrant as an illustration.
The Impact of Technical Debt
In most cases, technical debt can have serious implications if not resolved right away.
Some of the biggest negative impact of technical debt to a project or an organization in general are the following:
- Delayed product releases
- Problematic project scope
- Demotivated team members
- Low-quality output
- Lower revenue
- Lower overall productivity
- Client dissatisfaction
- Legal issues
Technical debt alone is also estimated to have a $3 trillion impact on global GDP according to Stripe.
I found a link coming from another blog by Andy Adams who used to be a Ruby Developer and currently, he is running a WordPress performance consultancy. He wrote a very insightful post—90% Projects and WordPress.
First, a quick review of Pareto’s Principle—80 percent of the work could be done in 20 percent of the time. The other 20 percent of the work basically takes the rest of the 80 percent of the time. This leads to a very interesting analogy.
With WordPress development, it’s easy to deliver the first 90 percent of a product but it’s extremely hard to patch all of those bug fixes, compatibility issues, regressions, performance problems, and whatnot. Everything else is built, but your foundation is obviously not quite stable because you still miss those 10 percent and you need to patch and hack around a lot of things just to get the rest of the 10 percent done. Again, this is a major, critical problem.
This happens quite a lot especially in the WordPress space where we do work in. What Andy essentially said that really made an impression is that WordPress makes things so easy that everyone can jump in and edit the themes, header file, install plugins here and there, update a few options from the backend, because this is essentially what WordPress enables you to do in general as an administrator.
On the other hand, since I used to work as a PHP Developer and I can also relate since my former background is a Java developer, I have done Python development as well; so, when you have an established programming language, you don’t have a CMS, you actually have to build something from scratch, you’re building the platform and customers know that they can’t really mess around with the codebase because they don’t have access to it. It’s extremely foreign, you don’t have all those panels where you just edit stuff, move, and shuffle stuff around.
This makes a difference between the app and platform development which most people understand is an ongoing technical cost for building a custom platform, and actually providing the very same thing but on top of the WordPress platform which is a foundation framework used to own about 40% of the websites out there.
So getting back to the technical debt topic, I stumbled upon an answer by Tikhon Jelvis who is currently working as a Lead Data Scientist in Target. He basically tried to sum up what technical debt actually means and what it also means for the organization. He identified it with several different criteria which are really interesting so I’m going to build upon all of them.
Assessing the Code Quality
Assessing the quality of code is critical to preventing or resolving technical debt. However, it can be subjective.
So, here are the areas to assess the quality of code.
The ability to sift through the code base easily and figure out what is built where, by naming conventions, by folder structures, by other elements that are extremely important to find.
Or when you have lots of dependencies, you should be able to quickly figure out what’s connected to what and be able to map the entire route in order to get the job done.
When someone with a minimum experience in terms of code base and limited background jumps in and starts reviewing the code base, they should be able to understand what most of the essential code base is doing by simply reading it.
This means understanding the following:
- Code comments
- Proper naming of variables
- Decent breakdown functions and classes
So, one must really find their way around and be able to start helping out quickly instead of just wondering what’s the purpose of this piece of code, how this relates to the other piece, and why there are so many pieces chained together in some weird and an unexplainable way.
This is what I deem as probably one of the most important ones.
Maintenance is being able to take a piece of code that’s built in a piece of a project and quickly start introducing changes and applying some updates and finding some fixes without the entire platform collapsing in front of you.
This is really the main differentiator between a properly built platform and a platform that incurs a ton of technical debt. One of the most common examples is if you build a platform from scratch or even if you are using WordPress and you build some plugins from scratch, just building your entire foundational layer, connecting different pieces together is easy because your entire foundation has been pre-determined to support it.
It has been intentional, thought for, and something that you have expected to be happening over time.
If on the other hand you bundle five plugins together, or five to ten large plugins together which aren’t necessarily meant to play well with one another, then it gets really tricky to start supporting certain things because you have lots of dependencies and you have lots of different behaviors coming from different pieces of software that are not meant to support your initial goal.
They may allow you to enable certain pieces to pull some triggers here and there, but actually making it happen is really a lot more complicated.
Technical debt leads to bigger challenges if you have performance halts, negative speed impact, and other types of challenges on a software level.
Good design and clean code help ensure a smooth-sailing development work.
These two are crucial in securing a high performance quality.
Just make sure that the code is correct and it does not make false assumptions and does not fall for different weird types of inputs from forums and from users.
It should not also store inconsistent data in the database due to lack of validation and so on.
This is how technical debt impacts a project. This is the main difference between a cheap one and a fairly expensive project. There is a difference between taking lots of shortcuts at first, and then expecting that things work well in the meantime.
Have you been a victim of poor code quality — either as a client or a vendor consulting or undercutting? What is your most memorable story?