We have all heard the first half of this refrain. I would hazard a bet that many of you can even remember yourselves saying it. Over my many years in IT, I have often heard this line from coworkers, bosses, and even clients. I have even been known to have said it a few times myself. Now what if we just stopped and listened. Who knows where those conversations would travel? Perhaps it could be the start of the next big thing. By now you will have noticed the second half of the title “Paying back technical debt”, and you are most likely wondering, what does it mean? Do we have it? And if we have it how do we get rid of it? It sounds nasty.
Missing the Train
Before we move on to the meat and two vegs, a little story. Many moons ago too many to count, I was sitting in a pub in London with a work colleague who was telling me all about this new technology he had seen and that he was considering investing some of his time into learning all about it. Now, I had a train to catch to get home, but I stayed for another pint and continued the chat. This technology we spoke about was VMware ESX. Having worked with Citrix for many years, I instantly caught on to the possibilities, and one more pint became three, yes I did miss my train and the next one too, but I have often thought about this little piece of serendipity and where my career would be if I had not taken the time to talk and just caught the earlier train.
I recently saw a post on LinkedIn about technical debt and it made me think about how sometimes we are so busy that we can’t see the forest for the trees.
Technical Debt
Now as promised a definition, technical debt is the extra and often neglected work that arises from the decision to take the easy path in the short term rather than doing it correctly in the first place. Now technical debt is something that is unfortunately painfully obvious after the fact and with the benefit of your 20/20 hindsight glasses. (Yes, we all have a pair of those).
But how does this actually occur, surely nobody will actually design and build technical debt into a deployment. But it is there, everywhere, so how does it happen?
When we are planning our glorious projects, we plan covering our contingencies, we work tirelessly to confirm or deny our assumptions, and build in extra time to cover for unforeseen issues, and then sit back and bask in glory of our planning and technical prowess.
Then, we push the project upstairs for financial approval, and we watch our slack days disappear in smoke – because, you know, costs. Then we are asked to rework the design to remove the “gold plating”, because it just needs to work. Hands up – how many of you have heard the statement “we don’t need a Ferrari, a Ford will do?” This is management speak for “it’s too expensive;” cost is the overarching and final arbiter in projects.
This was especially the case when IT projects were CapEx based (capital expenditure, or real cash from the bank) and front-ended, and OpEx expense (operational running costs) were not truly considered. Yes, the IT vendors attempted lip service with concepts like total cost of ownership (TCO) to show the whole cost amortized over the usage period of the project, but they never fully mapped to reality and were not fully trusted. That is because these models were incomplete. They were one-dimensional and only concentrated on the upfront cost element of the project. They did not look at the design aspects, the what-if scenarios. The “what if we used X instead of Y for the hypervisor” scenarios (yes, we know the cost differentiators). We had no real verifiable evidence to show the operational cost of that decision.
Early virtualization projects were a simple lift and shift, so there was no reworking of the background processes surrounding operating system deployments, no use of templates to speed up the deployment of servers. I am still finding environments that are manually building Windows and Linux servers from a build sheet using an ISO image because that is what they have always done. Why? Because they are too busy to change, not even realizing that by creating a template build for their servers or investing the time in creating an automated deployment environment, they would release that time spent manually building server for more interesting work.
Change is hard
What then happens is that those who are trying to motivate the change, introduce enhancements are demoralized; they either conform or leave, enhancing the status quo. The same is happening with automation. Some companies are already reaping the rewards of automating their repetitive tasks, allowing their staff to move on to more interesting work, and starting to make inroads into paying off their technical debt. Others are way too busy. All they are doing is compounding their debt, making the payback more expensive—just the same as if miss payment on a bank loan.
The real problem is not that we are too busy, but that we are inherently lazy. It is not a slight on us—it is a fact that our success as a species is founded on our ability to make things easier, to make our lives easier. A down side of this is that once we are comfortable, we tend to atrophy. It is easier to stay in our comfort zone. Automation is viewed by many as a harbinger of workforce reduction, but this is just not true. We just need only to look at history to see this fact. In the eighteenth century, artisan weavers smashed the looms of the industrial weavers with their sabots because they were fearful that their livelihoods were being taken away by the machines. Nevertheless, the industrial looms brought forth the first industrial revolution.
IT workers need to skill up on automation skills to keep relevant, and those who do not need to find a different industry to work in. IT is a knowledge-based industry, and knowledge is power. Automation done correctly reduces technical debt by removing the human element from repetitive work. Yes, it is expensive and time-consuming in terms of up-front costs, but here is the rub: the downstream improvement in stability and agility far outweighs this. So, to management, I say “Yes, sometimes you do need a Ferrari; if a job needs doing, it is always better to do it right the first time.” Please let’s not run the risk of history repeating itself and piling yet more technical debt on our next-generation deployments because we are not prepared to automate what we currently have, to allow our people the time to properly develop and deploy our next solutions. It is time to break the legacy cycle of “low cost at any cost” and just do it right for once.
