We have all heard this refrain. I bet many of you can even hear yourselves saying it. Over my many years in IT, I have often heard this from coworkers, bosses, and clients. I have even said it a few times myself. But what if we just stopped and listened? Who knows where that conversation could travel? Perhaps it could be the start of the next big thing. We now have a new term that relates to this message, and that term is “technical debt.”
Many moons ago, 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 was considering investing some time into learning. 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 been in the Citrix arena for many years, I instantly caught on to the possibilities, and one more pint became three. I have often thought about this bit of serendipity and where my career would be if I had just caught the earlier train.
I saw a recent post on LinkedIn about technical debt and thought about how sometimes we are so busy that we can’t see the forest for the trees. Technical debt is the extra work that arises from the decision to take the easy path in the short term rather than doing it correctly in the first place, something that is obvious with the benefit of 20/20 hindsight glasses. (Yes, we all have a pair of those.)
When we are planning our glorious projects, we plan for our contingencies, build our slack for unforeseen issues, bask in our planning and technical prowess. Then, we push the project upstairs for financial approval, and we lose our slack days—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”? This is management speak for “it’s too expensive”; cost is the overweening and final arbiter in projects. This was especially the case when IT projects were CapEx (capital expenditure, or real cash from the bank) and front-ended, and OpEx expenses (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 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 operation 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 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, they will release that time for more interesting work. What then happens is that those who are trying to motivate the change 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, 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 you do not pay back 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.