Software Modernization: What Is It?

If you do a quick search of software modernization and you’ll find tech jargon galore. Why is that?

It’s A Broad Topic

The topic of software modernization is fairly broad and doesn’t address specific kinds of software systems or businesses. This leads to the topic being discussed in an overly generic sense.

Sometimes, so generic that meaning is lost.

My goals for this article:

Help you gain some clarity around what software modernization is
Explore some causes that lead to the need for “modernization”
Examine a couple examples of what this might look like in practice

Think of someone asking you to “describe the colour red.”

That’s really hard to do without pointing to a concrete object, like an apple, that’s actually red!

I’ll be pointing out the “apples” of software modernization for you.

In A Nutshell

What’s the opposite of modern?

Old.

Old software systems are often called “legacy systems.“

Software modernization is about fixing problems that are caused by outdated technologies, processes, methodologies, practices, etc.

These have formed inside the software code and structure itself but also within the entire software development cycle.

This is one point I find often missing from this topic: problems inside software systems are often a symptom of poor development approaches and organizational dysfunction.

Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.
Mel Conway

What Makes Software Legacy?

Creating and maintaining software is more like tending a garden than constructing a building.

When we hear the term “software architecture” it might bring to mind the grand cathedrals of Europe.

Many people, including more than a few in the software industry, liken building software to constructing cathedrals or skyscrapers – after all why do we use “architect” for senior programmers?
https://martinfowler.com/articles/is-quality-worth-cost.html

In reality, our software is more organic than we would like to think.

Weeds grow. Soil dries up. Droughts happen. Lack of garden maintenance occurs.

In the software world, this equates to things including:

Quick hacks are favoured for getting a faster time-to-market leading to poor overall software quality
Developers not having the skills needed to create maintainable software end-up generating cruft
Not enough investment in software design leading to rigid software that cannot handle new changes
Technologies become aged and limit performance, scale and user interactivity
Outdated technologies unsupported for vendor patches introduce security vulnerabilities

Overall, everything together is sometimes called “software rot” or “code rot”.

Much like a garden, if not well maintained and tended, software code and systems as a whole “rot” as time goes on.

P.S. I wrote a book about getting started with dealing with software rot at the code level.

Poor Software Quality

Does the quality of software code really matter that much?

If we push to get our products and features to market as quickly-as-possible will there be negative effects?

Martin Fowler, one of the biggest minds and technologist of our time, says it well:

Here we see a clue of why internal quality does matter to users and customers. Better internal quality makes adding new features easier, therefore quicker and cheaper. Rebecca and I may have the same application now, but in the next few months Rebecca’s high internal quality allows her to add new features every week, while I’m stuck trying chop through the cruft to get just a single new feature out. I can’t compete with Rebecca’s speed, and soon her software is far more featureful than mine. Then all my customers delete my app, and get Rebecca’s instead, even as she’s able to increase her price.
https://martinfowler.com/articles/is-quality-worth-cost.html

Master JavaScript developer and coach Eric Elliott agrees:

We don’t invest heavily in software quality because our teams have big budgets (they’re a drop in the ocean compared to Boeing’s engineering budget). We invest heavily in software quality because it helps us move faster and save money in the long-run.
https://medium.com/javascript-scene/why-cutting-costs-is-expensive-how-9-hour-software-engineers-cost-boeing-billions-b76dbe571957

The irony: in a move to get products to market faster the trade-off is a loss of agility for the next set of products and features.

Higher quality software code means, in the long-run, more business agility.

This is what happens with poor internal quality. Progress is rapid initially, but as time goes on it gets harder to add new features.
https://martinfowler.com/articles/is-quality-worth-cost.html

Developers Developers Developers

Does it pay to have mediocre developers building your complex business-oriented systems?

Take Boeing as an example.

They decided to skimp on the costs of hiring high-quality software developers. This lead to critical issues causing a fatal plane crash.

More issues are still being discovered as this is written.

In Eric Elliott’s article “Why Cutting Costs is Expensive: How $9/Hour Software Engineers Cost Boeing Billions”, he says:

What could have been a huge win for Boeing had they not been obsessed with cost cutting turned into a big disaster that took a hatchet to the Boeing brand.
https://medium.com/javascript-scene/why-cutting-costs-is-expensive-how-9-hour-software-engineers-cost-boeing-billions-b76dbe571957

This article isn’t about how to attract high-quality developers. But I am saying that it matters – a lot.

The software engineering shortage is not a lack of individuals calling themselves “engineers”, the shortage is one of quality — a lack of well-studied, experienced engineers with a formal and deep understanding of software engineering.
https://hackernoon.com/2018s-software-engineering-talent-shortage-its-quality-not-just-quantity-6bdfa366b899

This is one major reason why many software systems are hard to maintain and add new products and features.

Software businesses that can attract quality software minds will be more likely to achieve their business goals that are underpinned by technology.

Modernization Triggers

In most software businesses, non-developer professionals don’t usually understand the wreckage that poor quality software can cause (until it’s too late!).

It can destroy entire businesses in the most (not so) extreme cases.

So, when do these quality issues reveal themselves to the business?

Here are some business drivers that might trigger the need for software modernization:

The need for a mobile application and (therefore) a back-end API for that application to access data
A business wants to move some of its services to a cloud-based service provider (for cost savings, etc.)
To increase the chances of its software business to be acquired
To prepare a system to integrate well with incoming software acquisitions

In all of these cases, non-developers might expect these tasks to take a couple of months of work. But in reality, due to poor internal software quality, it could be months or years of work!

Mobile, for example, is pretty huge.

If your Saas product cannot compete on the mobile playing field then you’re most likely going to fail to grow as much as you could have.

Or your business will just die.

With older systems, this may involve a large amount of work to get the required parts of that system up-to-snuff.

Some Examples, Finally…

Moving on from some of the causes that might lead to the need for software modernization, let’s look at some examples.

I hope you get the idea that hiring quality software developers and focusing on high-quality software design and practices do matter a ton.

Ignoring these facts is a major reason why software systems turn into a state of disarray.

Let’s look at a few examples that highlight some ways we could modernize a legacy application.

Cloud Migration

Before “the cloud”, most non-trivial web applications would be hosted on on-premise dedicated servers.

What’s wrong with that?

Owning your own servers and backup hardware (in case of failure) is really expensive.
Maintenance of that hardware/server(s) is expensive
They are difficult and expensive to scale
They take up physical space (you pay for the room to store these things)

In our “modern” age (the current age is always modern….) the cloud is the solution to the overhead and costs of having to maintain your own hardware/servers.

Cloud services directly address the above issues. What if:

You didn’t have to maintain that hardware?
Servers were easy to replace and scale?
Your hardware didn’t use any physical space?
Hosting was less expensive overall?

Imagine an older Java or .NET application that required a high availability or uptime.

Owning your own hardware for this would be very expensive.

One technique for moving an antiquated system over to the cloud is the “lift-and-shift” migration approach.

This is when you use virtual servers from a cloud hosting provider (like Azure or AWS) to replace your physical servers.

Overall, this can be much less expensive because the cloud provider is responsible for making sure the infrastructure and the hardware are kept up-to-date, running well, etc.

If you need a bigger “machine” because your business is growing then you can do this with a mere click of a button.

Azure has some guides around different approaches to migrating an existing system to the cloud.

One system I’ve worked on did this successfully and significantly reduced costs, gained an increase in the web application’s overall performance and made hardware changes extremely simple.

Conflicting Teams And Slow Time-To-Market

Businesses who’ve grown over time can slowly (or quickly) transition from having one small team of software developers to dozens or even hundreds of software developers.

The developers might be working in the same software code-base as each other.

However, what happens is:

The work of one developer conflicts with another
A feature that was planned to be released 1st will actually need to rely on another larger project to be completed first due to architectural changes, etc.
Deployments get confusing since completely different products end-up breaking each other

This is a sign that the software system in question is too big and singular.

Developers keep conflicting with each other.

One tool in software modernization is to split up the software into isolated, independent and autonomous components that integrate with each other where needed.

I’ve written about how microservices and other approaches can help with this.

This involves re-architecting an existing software system so that:

Teams can have ownership of their own applications
Teams can deploy their new features without depending on other teams and being blocked by them
Software components will be much smaller and therefore easier to maintain

Conclusion

If this topic interests you some more I’d recommend looking at Martin Fowler’s article “Is High Quality Software Worth The Cost?”

Ultimately, software modernization is about improving the quality of your software systems so they are secure, flexible, agile and maintainable.

Ignoring quality in favour of a fast time-to-market can actually work against you in the end.

Thanks for reading!