We are putting out fires this week!
We have a relatively new client who, despite best efforts, has found themselves in quite a bit of technical debt. And, let me tell you – this is a “learning moment” if I ever saw one!
What is technical Debt?
Technical debt refers to the underlying costs associated with prioritizing elements like speed, ease and cost, when choosing IT solutions and strategies.
We get it. Sometimes the fix feels cumbersome and expensive, and we just want to get things up and running as easily and cheaply as possible.
Unfortunately, what often happens is that easy and cheap and older systems, cost MUCH more money to maintain and fix. The costs are sometimes hidden when organizations don’t realize that legacy systems are inhibiting growth and scaling; or that employee productivity is down on slower systems; or even that the client attrition they’re experiencing is a result of lagging technology delivering a sub-par customer experience.
And then, just like with financial debt – the longer you wait to catch up, the more the cost is compounded! Downtimes and crashes, incomplete projects and missed deadlines, all contribute to accumulated cost to fix the situation.
So what happened with our client?
Company X, as I’ll call them, came to us about a year ago. They had a 6 year old, on prem server, with no redundancy. We encouraged them to partner with us for top level IT Strategy; but for many valid reasons, they chose to engage us on an hourly basis, to fix major problems.
*First red flag – an engaged IT department (as we would have provided) fixes breaks as they occur. Having to engage us hourly, in critical situations, is not best practice. But we try to do what we can.
Another challenge with Company X, is that about 40% of their computers were not domain-joined. We identified this as bad practice and a security risk. Fixing this was a challenge to the budget and presented as low priority to our client.
*Red flag 2 – Non domain-joined computers present a chink in the armor, if you will. It seems low priority when it’s not a current crisis – but then it is.
So, last week, Quickbooks crashes. Company X has experienced this before. In the past they rebooted the virtual server and went on. We were instructed to do only that.
It did not work this time. There was too much file corruption and the core functionality was down.
This was a crash and Company X needed to get back UP!
But here we are working with old systems and a stack of previous band aids. (The 40% non domain-joined units are a different issue, but tangentially related to trying to get the server up and running.) This needs a lot of work to rebuild, correct and reconnect. And, we know how to do it! BUT -Company X really wants to avoid suspending business for 48 hours to fix the mess. And of course, this type of correction is far more costly, in many ways, than it would have been to initially invest in a more robust system.
So what will Company X do? We don’t know yet. We highly recommend that they let us implement best practice configuration (which involves shutting down for 48 hours) and engage us in our Diamond level service. We can provide an assigned CIO to develop strategic plans, complete small and mid sized projects, provide unlimited onsite and remote support, a robust cybersecurity service, backup management, access to automation – the LIST GOES ON! We think this is the most effective and efficient way to solve Company X’s list of issues relating to these old systems, and get them on track with an appropriate IT strategy and new technology.
Of course, we’ll also provide some other options and will always do what our client feels best for their organization. And I will keep you updated on how things go for them.
How do I know if my Organization is Suffering from Technical Debt?
According to expert and author Steve McConnell, there are 2 types of technical debt: Intentional (We don’t have time/budget/resources so we’ll do it with ease instead) versus Unintentional,
which is essentially the “non-strategic result of doing a poor job.” Then Martin Fowler took it a step further to delineate between prudent and reckless technical debt. And – to make matters more complicated – there are 13 different types of tech debt!
The bottomline – don’t let Technical Debt compound by waiting for a potentially devastating crisis. Contact firstname.lastname@example.org if you’d like a systems consultation with our experts!
Technical debt usually accumulates when organizations prioritize speed, ease and cost over long-term sustainability when choosing IT solutions and strategies. Examples of technical debt include legacy systems which are slow, outdated or difficult to maintain; software flaws which are not fixed; incomplete projects; and poorly designed code.
In scrum, technical debt refers to a backlog of aspects of an IT system or project that need to be addressed in order to improve performance. This could include tasks such as refactoring code, improving existing features, and updating outdated systems. Technical debt can lead to costly problems down the line if it is not addressed.
Technical debt can be a useful tool for businesses. It allows organizations to quickly develop and deploy products or services, helping them get to market faster. However, if not managed properly, technical debt can quickly become unmanageable and have serious consequences for the long-term stability and reliability of an organization’s IT infrastructure.