This is my McGyvered standing desk:
It is steady enough, didn’t cost me much (scavenged all the parts in the office), and was built in half an hour, including scavenging time. It is a low-cost solution and it fulfills its purpose: I can work while standing.
As much as I love it, it is not a very resilient piece of interior architecture. It is based on components that are not meant for that, I don’t know anything about their resistance, neither their resilience. It’s been poorly conceived. Actually I didn’t conceive at all, just built. It’s been built in a hurry because I needed to prevent my back from being blocked, the only testing I did was: put the computer on, and see if it works. It does not have any of these features standing desks have, such as adjusting height or being stable. It is fairly non-evolutive, I could not add a new screen or more space for a notebook without risking having it capsizing. And finally, I hacked the procurement and office organization process by not asking my boss for that, which could have ended in pretty bad consequences, as he’s a bit picky when it comes to office layout.
By keeping it for more than 2 weeks and not thinking about replacing it soon, I’ve actually introduced a technical debt into our office.
I have a (poorly built, non resilient, but working) standing desk now. In achieving that, I lowered the need of investments on an actual standing desk. Any evolution (adding a screen, more space for a mouse or notebook, a keyboard, changing height, etc.) will require hacking, lower the resilience of the overall structure, cost more than it should, or might not be possible at all. The rotten parts of my desk (mainly the meta-structure) are kind of hidden, so investors (my boss) can’t really tell it needs to be replaced by a proper solution. Additionally, I opened a path that other people might follow. Non respect of the process may be interpreted as an absence of enforcement, resulting in the effective abandonment of the process. And as far as you know other guys in the office may start scavenging parts here and there, and building contraptions that may or may not result in catastrophes such as that:
Finally, and worst of all, it becomes the corporate standard for investment on standing desks. For subsequent people wishing a standing desks will have to justify why they can’t just hack it the same way I did.
A debt has a few general characteristics:
- It has a cost: interest fees
- If you don’t repay it, people are getting angry
- The longer you keep it, the higher the interest you pay
So why am I talking about desks? Because technical debt in development is exactly the same. It happens in software that you end up with a piece of garbage which just fulfills its purpose, but is built cheaply and in a hurry. Call it an MVP, a PoC, or a tool. It goes to production. Whatever is the reason, we keep it, or we reuse it. Even when it’s is a big ball of hacks holding together by scotch tape and sugar coating, based on technology that is not so good for what you do, is badly used, went through little or no testing. But it’s kind of working, so move along!
By keeping this kind of things alive, you mostly pay interests until you replace the piece of garbage. Let’s consider a simple common architecture:
Let’s say you’re a lucky chap, you built an MVP and it worked! You now have proven that what you want to build is feasible, just have to transform it into something that does not look like you built it in 1978. The intuitive way to do so for a business man is start where the thing will bring you money, i.e. sales, i.e. what is visible: the front-end.
Your front-end depends on your API, which depends on your back-end. If your backend is unstructured and hacky, you’ll have to perpetrate the same hacks all the way up from your back end to your front end. Most hacks will be invisible. And you’ll be able to record tons of errors in the backend for which you’ll compensate with more hacks, and finally spend more time trying to hack our way around inserting features. Then your management is gonna start asking questions, why is it taking so long? Why so many regressions? Why the sudden drop in quality? The answer: the debt you’re paying for. The longer you keep it, the bigger the interests. Until you pay only interest fees.
Anytime you need to compensate for something missing because of technical debt, that is interest. Something you should not be working on.
So what is the solution? Well the only one I experienced is painfully easy to guess: get rid of the debt, either repay it or declare bankruptcy.
- Prevent more debt: keep it clean, don’t keep refactoring for later. Shit is always gonna be required ASAP, so you’ll never ever have time to refactor later. Plus you’ll start accumulating hacks around your current hacks.
- Verify you’re actually paying a debt, and show it: make it visible, deciders will not decide to spend money on refactoring something they think is working if you don’t prove otherwise. If you have a big ball of crap that can’t evolve, chances are you’ll have to work your way around it in other components. Triage defects both by team who will take care of it, and by root cause. Identify those unit of work you spend working around problems rather than solving them.
- Kill your ugly babies while they are still latching. The sooner you do it, the less debt you accumulate, the easier the refactoring will be
- If you did accumulate a lot of debt, don’t start refactoring on a ball of crap. I’ve done it before, we set a very clear isolation layer between old and new code to prevent having shit rolling up… and yet, as the technical debt has accumulated beside just code, into the core of the design. Malpractice perspired through the isolation layer, the refactored version had to work around all these small hacks. Result: we did as bad. Trading-off has a cost apparently. Instead, if everything needs to be rewritten, rewrite everything, and
- base your strategy on strategy, not technology. Declare bankruptcy, stop wasting money around the old code. It might be more complex, but it is probably much more cost and profit effective in the end. Use a clean architecture, start small, don’t aim a new v1 with all the features. Clients needing migration will have to wait until refactor is complete. New client can use the new, small, simpler product and get the updates on the road. Once the feature-set is satisfying, migrate everybody. It should be a more pleasing, and faster experience anyway.