Technology

Stop Kicking the Can Down the Road: The Dangers of Technical Debt

It can feel like you’re saving money by delaying a technical fix or update, but in reality, you may be setting yourself up for bigger costs later on, according to speakers at the ASAE Technology Exploration Conference last week.

It may not look like it, but your office is likely full of things that are slowly decaying—and without a plan, it could prove a real danger down the road.

At the ASAE Technology Exploration Conference last week, the concept of technical debt—or delaying large transitions for reasons of cost or management challenges—came up frequently in education sessions. It raises an important question for IT pros: What’s the best way for an organization to maximize its investment in IT infrastructure?

In a Tuesday session, Matrix Group International’s “Chief Maxximizer” Tanya Kennedy Luminati, who helps manage the day-to-day operations of the MatrixMaxx association management system (AMS), said her job often puts her in contact with associations looking for ways to mitigate layers of technical debt related to  old tools, old platforms, or old processes.

No one wants to get a new AMS or change their CMS if everything is going great and it’s up to date.

“No one wants to get a new AMS or change their CMS if everything is going great and it’s up to date,” she said.

Now, every organization has some technical debt. For example, you may be putting off updates to the latest operating system on your association’s laptops because of some legacy apps that are mission-critical. Or perhaps you’re using an old piece of database software because your staff prefers using the legacy tool, and there’s no security risk that’s forcing you to make an immediate change.

“You have choices to make, and really, tech debt is that delta between what you choose to do and what that’s going to cost to change that,” added Matrix’s chief technical officer and “Shogun of Lunch,” Maki Kato.

Letting Debt Get Out of Hand

All of that is to say that carrying some degree of technical debt can be useful—even desirable. But letting things just hang out there too long can come back to bite you, if you’re not careful.

Uber is a good example. In a recent podcast by the MIT Sloan Management Review, Stanford organizational psychologist and management science professor Bob Sutton described Uber’s “spaghetti ball” of organization.

“They took all of the different services for ordering a car, for tracking a car, and it was bundled into this big ball,” he said. “And when part of it crashed, the whole thing would go down, and it was very hard to move quickly.”

The company’s approach to regulation complicated matters. Essentially, Uber grew by ignoring local and national regulations, assuming that by the time the regulators caught up, the company’s service would be so embedded in the market that it would be allowed to stick around. But this created a lot of issues a few years in, as those regulatory problems all came to a head at once.

Now apply this to every other part of the company, including the technology that runs the app, and you see the problem.

In your association, you can get into a situation where just trying to get things up to date ends up costing you significantly more than starting over. You might have your own “spaghetti ball” to untangle if you don’t play your cards right.

Can Technical Debt Be Avoided?

The key to mitigating technical debt is front-end planning and decision making, Luminati and Kato said. They recommended avoiding customized code where possible, as it can break later on when updates are needed; opting for a cloud-based “as a service” variant; and planning for maintenance and upgrade needs over a long period of time.

But even with “as a service” offerings, which put the ownership of the tech debt in someone else’s court, you should still monitor the vendor to ensure they’re keeping things up to date. “One caution: Just because it is a service … doesn’t necessarily mean you’re getting automatic upgrades,” Luminati said.

As is always the case when building IT infrastructure, decisions related to the life cycle of technology systems shouldn’t live with the IT department alone.

“Tech is not something that’s going to happen on its own,” Kato added. “It really needs to be the CEO—the board really needs to be part of the discussion and the conversation of where things can go and how the tech is going to support it.”

(Andrey Atanov/iStock/Getty Images Plus)

Ernie Smith

By Ernie Smith

Ernie Smith is a former senior editor for Associations Now. MORE

Got an article tip for us? Contact us and let us know!


Comments