The Hidden Costs of Bad Solutions

When it comes to developing technology-based business solutions, it is tempting to go with the least expensive option or provider. The initial cost estimate is typically communicated up front, making it an easy item to negotiate and compare. The probable quality of the end-product may be much for difficult to evaluate. This makes the seemingly pragmatic choice of lower cost the more defensible one. What can often go unnoticed is that there is a real hidden cost of going with a bad quality solution. This article outlines how these hidden costs can hit your bottom line over time and how you can minimize it.

Imagine you need to build a new house. You could hire a good contractor or a “cheaper” contractor. In either scenario, it is likely your house will be inhabitable on day one. If you went with the cheaper contractor, you may even feel good about the money you saved for the apparent good result. What you may not know is that the cheap contractor took some shortcuts during construction. A few months later, you are dealing with dreaded house repairs and the additional time and money.

The same concept applies when developing technology solutions to solve business problems. Whether you develop a good or bad solution, it is very possible the solution will meet your requirements on day one. The hidden problems lie down the road and may manifest in three ways: Maintenance Costs, Rigidity Costs, and the Opportunity Costs.

The Maintenance Cost

Maintenance costs are perhaps the most self-evident. Like a shoddy construction job, a bad solution will break more often, with graver consequences. How does this cost manifest? A constant amount of bugs, endless UAT and support cycles, unplanned outages or unhappy users, all leading to frequent headaches for the IT department. For vendor-supported solutions, this extra upkeep can quickly add up, perhaps even beyond the cost of original development.

When developing a robust solution, several decisions are made from large architecture approaches to small development items. Hopefully, the important decisions are reviewed and approved to ensure quality, but in projects where the developer is brought in for their specialized expertise, they often have wide latitude when making architecture decisions. After all, they are the expert. The customer may not have the expertise to review or challenge these decisions, just like you may not have the expertise to check your house contractor’s work.

So how we avoid these costs?

Proper development hygiene must be enforced! Practices like functional programming, proper encapsulation of logic, readable code, and other solution-specific development standards need to be followed, even when it extends the development timeline.

Automated testing is also very helpful. For any solution of medium to high complexity, developers should write automated test scripts to facilitate regression testing when possible. Some developers may push back as this requires additional effort up front. However, I have always found that every hour spent writing a test script pays for itself in the future, not only in time saved during future tests, but more importantly, in keeping potentially dangerous bugs from making their way to the production environment.

Finally, the more boring answer: proper technical documentation. I am not talking about just putting screenshots of code into a Word document, or simply listing all the development objects in a package (thanks, I can read). Good documentation allows future developers to separate the signal from the noise by highlighting areas of importance and providing troubleshooting tips. This can save an enormous amount of time when (hopefully seldom) something breaks and requires a fix.

The Rigidity Cost

No matter how good you may be at seeing the future, requirements almost always change throughout the lifetime of a solution. End users often find new use cases they did not think of during design. Some solutions become the victim of their own success, causing other user groups to want to adopt it, therefore expanding its scope. The outside world is always changing, forcing organizations to constantly adapt their processes in response to new opportunities and challenges.

Rigid design decisions made in expedience (in service of time) or ignorance (lower quality) can lead to solutions that are not easily adaptable. When conditions inevitably change, this rigidity cost may manifest itself with unhappy users, excessive change orders, project delays, major refactoring, or in the worst cases, a complete rebuild.

Well-built solutions are not only resilient enough to withstand unforeseen conditions but are also agile enough to adapt to unforeseen requirements.

Well-built solutions are not only resilient enough to withstand unforeseen conditions but are also agile enough to adapt to unforeseen requirements. The best solution architects, relying on their experience and knowledge of technology trends, can envision how requirements may change and develop their solutions in a way that allows the organization to address these new requirements without a major rebuild. This can save organizations an enormous amount of money and time. It is much easier (and cheaper) to build it right the first time than to enhance a solution that is already live.

Imagine you needed to build a new house for your family. Today, it is only you and your partner, so a single floor house would be adequate. However, you know there is a good chance that your family will grow in the future. While you may not have the budget to build a second floor today, it would be wise to spend a little extra time and build a solid foundation that can support two floors in the future. That way, if your family does grow and you need that second floor, you can add it to your existing house instead of having to build an entirely new, 2-floor home.

In more relative terms, this may mean you encapsulate your business logic into a more modular microservice that can be used by other applications in the future. Perhaps you spend a little extra time to make your solution more configurable to avoid future code changes. The key here is only do this when it makes sense! You don’t want to needlessly add complexity to a solution if there is not a significant chance it will be needed.

The Opportunity Cost

There is a the reason you don’t mind sitting at home doing nothing when it’s raining outside, but when the weather is sunny and warm, you feel anxious that you are not out there enjoying every second of it. If you have the opportunity to do something better with your time, you pay a hidden cost for not taking advantage of it.

Similarly, IT departments generally focus on two functions:

1.       Support existing infrastructure and applications (i.e., keep the lights on)

2.       Provide innovative solutions so the business can run more efficiently (i.e., add value)

The more time and money spent on the former, the less you can spend on the latter. In other words, not having bandwidth to innovate is the opportunity cost you pay for focusing too much on supporting existing solutions.    

For organizations, there are no shortage of opportunities to innovate. Due to the rapid evolution of technology, the question is usually not if a project has a good ROI, but rather which project has the best ROI. The bottleneck is often internal resource constraints. Even for outsourced solutions, some degree of internal participation is needed for requirement gathering, coordination with end users, knowledge transfer, etc.

IT departments need to balance resources and budgets, and unfortunately, innovation can be sidelined in favor of maintenance.

The problem is that bloated, rigid, high-maintenance solutions will eat up a lot of time and energy from an IT department. When resources are too busy devoting their time/energy supporting existing solutions, they will not have bandwidth to work on new projects. IT departments need to balance resources and budgets, and unfortunately, innovation can be sidelined in favor of maintenance. Back to the house example: if you spend too much time doing routine repairs, you will never get a chance to work on that new deck or kitchen island.

This opportunity cost is hard to quantify, hence why it is often left out of the calculus. Can you think of how many times your organization left a project on the “back burner” because it did not have the bandwidth to pursue it?

While, in hindsight, not building time-sucking, high-maintenance solutions in the first place would be preferred, what else can you do to minimize this opportunity cost? Outsourcing can provide some additional relief here, although as explained above, it will always require some internal participation to be successful. The key is to pick a partner that can be trusted and provide the right level of oversight. Otherwise, you’ll end up with more bloated solutions to maintain, further trapping yourself into a toxic cycle of technical debt.

 What’s Next?

So how do you quantify the cost of bad solutions? While it may be hard to foresee whether a solution will be good or bad, it may not be that hard to assess the impact to ongoing operations. As an IT leader, what percentage of your budget do you spend on maintenance or enhancements versus the amount spent on new developments?  By properly implementing some of the concepts described above, imagine what you could accomplish if you could spend less time keeping the lights on and more time enabling technology to drive more value for your organization.