So there’s this term – technical debt – that’s so popular nowadays. But I feel that some people did not get what it really means and how to use the concept. And so people get lazy and stop doing things right because of something being 0.2s faster to do and ‘we have to ship, no time now’.
So what is technical debt?
It’s a tool. Similar to a loan from the bank. For example: You skip commenting on the code now, but you will have to do it next month. And it will be more costly than today when you had the ideas and overall inner-workings of the script in your mind. You might just spend twice as much commenting that script after 30 days of forgetting about it. (just like banks charge interest, technical debt has its consequences)
What isn’t technical debt?
So, in my opinion, it’s not a get out of jail card. There are things that are just no. Not ok.
What technical debt is not:
- is not an excuse to do something poorly;
- is not an excuse for endless improvisation;
- is not to be used without notes. Document the debt and don’t forget to do the work when the waters are calm;
- is not an excuse to throw away logic and performance;
- is not unintentional;
- and it’s not a mess. A project has constraints, technical debt should be a calculated risk, meant to be fixed when the circumstances allow you to;
Is technical debt bad or evil?
No. It’s just debt. Following the loan example, I gave earlier, taking out a loan is not bad or good. A loan is just a tool used to deal with something, based on certain constraints. I see technical debt the same way.
And if we think about it, most software products have a certain degree of technical debt. Especially in agile environments where working software is the measure of progress. But a good team or a good developer always makes intentional technical debt. That means they ‘pay the debt back’.
A Magento example
I won’t give theme names, dev names or anything. The point is for all of us to work more responsible, not to blame people. We need to constantly learn and remind ourselves not to be lazy when it’s actually not being lazy, just being reckless.
Let’s set up the stage:
- Magento 1.x installation with custom theme;
- A category page with layered navigation and about 36 products per page;
- Decent amount of traffic and acceptable VPS specifications;
- ‘Experienced’ Magento developer that modifies theme without using child theme;
Enter the request: We don’t use/need the compare and recently viewed features of the store. Please remove it.
As with any CMS, or e-commerce platform… or problem… there are different ways to do this.
How did the respective developer dealt with this? With CSS’s old faithful: display:none.
What was the actual solution to this customer request?
Removing compare
Even if you’re new to Magento, a quick Google would have come up with better solutions. But hey! You know CSS! Good for you sport!
Example for removing the compare sidebar block:
In local.xml of a child theme, just insert:
<?xml version="1.0"?>
<layout version="0.1.0">
<catalog_category_layered>
<reference name="left">
<remove name="catalog.compare.sidebar" />
</reference>
</catalog_category_layered>
</layout>Easy, peasy! Of course, clear the cache after saving the file.
In terms of removing the compare button, I went the extreme way, but by no means reckless: created the child theme, and overridden the view.phtml file with the compare buttons actually removed from the template. It will take 10s to add them back in. But it’s senseless to load that PHP code to determine if we need the button or not. It was just a couple of if’s but nonetheless, never used by the store.
And what about the recently viewed products feature?
Well, there was actually a theme extension that handled that. Just disabled that extension. Note that the store was not using the right column on the product page, so nothing appears there. (some themes have a recently viewed block there, easily removable via XML similar as above)
In the end, I also removed the CSS code responsible for the compare function. Less bloat = happier store.
How did I found these things?
After endless debates with the former developer, the client asked me to look around in regards to improving TTFB. (major costs – as in upgrading the VPS were the plan)
I found out about the CSS ‘magic’ by not seeing the recently viewed products block even if the extension was enabled. That struck me as odd. So… I found it just laying there with display:none.
Disabling the recently viewed extension reduced TTFB by almost 700ms. That is a lot. So we were clearly dealing with a bug over there. After notifying the client he decided it’s not the time and financially smart to deal with solving that bug since they are not using the feature. So we just disabled it. Done! Faster store!
note: when explained the issue to the people involved, the official explanation was that there was no time to look for a proper fix for this task. Idk. From that point, I just started assuming the dev was not experienced.
Why was the fix not appropriate?
Removing does not equal to hiding. Just as hiding dirt under the rug is not cleaning up.
Taking the time (but yet again, if you advertise yourself as an expert, the basics should be easy) to do things properly the first time. Especially when the right way takes the same amount of time as the weird workaround.
Furthermore, the number of DOM nodes were pointlessly increased. That sidebar compare block? 400 nodes. The add to compare button? 3 nodes (multiply by 36 as there were 36 products on the category page).
As the number of DOM nodes increases, performance/responsiveness (as in how fast the application responds to your actions) decreases. Because even if our devices get more performant, at the end of the day the DOM is slow. Of course, repaints and reflows are even slower.
Just to be clear: the reduction of ~550 DOM nodes did not make the store magically faster. But continuing on bad practices like these quickly adds up and we end up with a sluggish experience.
Just by doing things right, as in the way the CMS is meant to be worked with we got:
- less PHP code loaded;
- less CSS code loaded;
- less DOM nodes created;
- a better TTFB and overall performance;
- did not spend any more noticeable time than using the CSS workaround;
- a sense of accomplishment, since we did things the right way;
- easy fallback to adding back functions since, as the good practices state, we’re now using a child theme;
- an easier environment for whoever will work next on that Magento store;
How I counted DOM nodes (HTMLElementNodes) in Google Chrome’s Dev Tools Console? Using this handy snippet:
document.getElementsByTagName('*').length;Why I don’t consider the above example as technical debt
Because it was not assumed and reckless.
By not using the proper ways of removing a block in Magento and when the performance comes into consideration instead of fixing your initial mistake a hardware upgrade was suggested.
When you decide to take the quick and dirty route, you should always note that, and fix that as soon as the opportunity to do that arrives.
In the end
Choosing to use the technical debt method of developing software should be a conscious decision and well documented.
I don’t consider technical debt things that are done just plainly wrong. Sure, maybe if there are no consequences or something. But even then, if there is a clear way of doing things, appealing to weird workarounds is just reckless – and at least have the decency not to charge the client as crazy if you know you’ve been bad… or you know… just DO IT RIGHT.
Some things are just easier to deal with when doing things properly. So take the time to do them right the first time, so that debt won’t bite you in the ass later.
I often use technical debt. It’s a great way of shipping stuff fast. But there is always a ‘post-project’ time planned, time in which I pay my debt back to the gods of software.
I hope this article will help you get rid of weird ideas or laziness and inspire you to take that extra hour and do things properly. You’ll be thanking yourself in the end for a job well done.
If you got this far, did you see my 5 things to do as a programmer in 2020 list?