I'm helping a friend right now on a project. It isn't a "software company" in the traditional sense, but they occasionally build software tools to support and grow their business. Well, "occasionally build" means a consulting company came in and built a tool for them.

Then, that consulting company moved on as consulting companies often do.

So my friend has a Ruby on Rails app a few years old that they can can't support or maintain themselves. They now need help to maintain and improve this legacy app that's important for their business.

They also need more functionality. So they hired new developers to come build more things.

But here's the catch.

The new developers don't enjoy Ruby on Rails apps. "It's peaked." They love Laravel, the new hotness, instead. So they built my friend a new Laravel app. The app does its job. My friend is happy.

Then, these new consultants moved on as consultants often do.

My friend now has an enormous new problem.

He has two separate apps to support and maintain. Two different databases. Two hosting and deploy situations. Two code bases someone separately needs to figure out and grok to help.

And here's the kicker: he'd love if the two apps were actually integrated together.

Integrated together!? They should have just been the same damn piece of software!

Let me date myself. I've been professionally building software for 19 years.

And here's a trap I keep seeing development teams fall into over and over again. They give into the lure of the new sexy framework or architecture or tool, but to the detriment of whatever's already built in that organization with the old framework, architecture or tool.

I was working on another project recently. The client already had an app using Postgres as their database server. A new consulting team came into build additional database functionality and chose MongoDB as more tech to introduce to the stack. What did this dev team use to justify their choice to the business team writing checks for this new app?

"MongoDB is faster."

The business didn't know enough to push back or question this choice. Who doesn't want faster?

Truth was: this app needed to support very little throughput. To make matters even worse, these developers went over budget bringing in MongoDB because it wasn't something they were deeply familiar with. They were just attracted to the shiny new tech, not whether it was solving a real problem.

Now, like my friend, this company has two pieces of database architecture to support, or has to decide on spending yet even more money and time consolidating choices.

I started at Accenture building things for huge banks and governments. I've built things for presidential campaigns. I've built tech startups that have been running for 13+ years. I've seen my fair share of old and new code.

And one of the biggest pains these companies have isn't the legacy app they need to support, it's the proliferation of new things in their organization. Things organizations now spend mountains of extra time and resources to support because people inevitably get bored and keep bringing in new things.

Developers are prone to point to legacy code and claim "IT'S TECHNICAL DEBT." "The Ruby on Rails choice was fine before, but it's not good enough anymore in the word of newer frameworks." "The new thing is so much better."

But the reverse is actually true.

Technical debt is defined by:

“Technical debt is a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution.”

Really, it's the new solution that's technical debt.

Building the new stuff with languages, frameworks, and tools that are attractive and are more familiar with may be the easier implementation. It might be harder to learn the old code and improve it. But the key is what is the BEST solution, not the easiest or sexiest.

In these cases, the harder version is the best version – to ignore a basic desire for shiny new things and embrace the old way.

P.S. If you need any help building software, give us a shout. I’m sure we can help.