Writing software that is still maintainable in 2020

It's now a new decade, and suddenly everything written, designed or programmed in 2002 (let alone in 1992) looks old, rusty, and maybe not up to today's standards. If a software written in 2002 fails, developers have the tendency to say, "Yeah, but it's almost ten years old now." But once 2020 is here, we might feel exactly the same about software we write with latest standards of today.

Still, lots of software that we write today, will be in production in ten years. In fact, lots of software written in 2002 will be in production, too. And maybe even code from the 1990s (yikes).

A little forethought leads us to ask the question: how could we write software that can meet the requirements, operate and still be maintainable in ten years or more? What are those design principles that avoid developers to escape that dreaded maintenance nightmare old code often causes?

Of course, this is a much broader topic than can be discussed in a single blog post, but I wanted to list four choices that in my opinion lead to applications that stand the test of time, are maintainable, and have an upgrade path. These are:

1. Tools, languages and platforms come and go. Choosing a programming language, development IDE and even the underlying operating system/platform is fundamental choice that affects the resulting application in many ways. However, no tool, language or platform is immortal. Visual Studio, .NET and C# might be the choice of today, but how about in 10 years? The bottom line: choose wisely. A broadly-adopted language/tool/platform is often a safe choice. You might lose a bit in the cutting-edge productivity, but in the long run, you usually gain.

2. Focus on a loosely-coupled architecture that allows change. There are two important words to note: loosely-coupled and architecture. By loosely-coupled I mean applications that take the possibility of change to the heart. Just like tools and languages can change, so can databases, patterns and user management, for instance. Instead of tightly-coupling everything into a big snowball that is impossible to stop once rolling down the hill, focus on lightweight parts, that can be changes almost at will. Naturally, some things need to stay fixed, but many parts of the application should be switchable to something else.

The other word was architecture. Yes, your application needs an architecture, and it's better to have one that works. As well as on the coding level, keep in mind the possibility of change on the architecture level, too.

3. Keep things simple. We developers could talk day-in day-out about the best programming language, features thereof, ingenious ways to solve a problem, and so on. But in the end, maintainable code is often about simplicity. Often those who are assigned the tasks of maintaining code are not those who wrote it in the first place. Thus, the original developer's logic might not be immediately clear to you, especially if there is no documentation (how often do you see a coding project with too much documentation?). Although it is indeed nice to prove your technical ability with clever coding tricks, basic code is often the best when it comes to understanding it. Because if you don't understand the code, it will be difficult to maintain.

4. Document and record the expectations. Yes, documentation is often the last step in a development project, but this need not be the case. In addition to clear documentation (especially, remember to write down why something was done, instead of just how), make sure you record in some way or other, the expected results of your applications input and output. Unit tests are a great and modern way to do this, but the problem is that unit tests are often related to the tools you use. It's probably also worthwhile to record the broad expectations on paper documentation as well.

With these four tips, I believe many applications would become more robust to the changes that the day after tomorrow mandates. If you are already using all of these techniques in your own development projects, then great! In my opinion, you're all set to the new decade!

PS. In the business world, performance is often evaluated with a so-called scorecard (in good and bad). A software audit could create a similar "scorecard" on software future-proofness. Stay tuned for more ideas about this later.