How to Make Your Software Last 15 Years

In 1940, an $11 million dollar bridge over the Puget River in Tacoma, Washington, buckled and twisted in 40mph winds before snapping and collapsing only 4 months after it was opened for public use. Its construction was supposed to endure strong winds, but it collapsed due to a fundamental engineering oversight.  “Galloping Gertie,” as she is known, became a famous example of the risks involved in pushing forward with a design that may save costs but has not been fully tested. 

Today, making good software is somewhat like constructing a strong bridge or building. If you build along the lines of Galloping Gertie without understanding the implications of untested designs, the building will not last.

When it comes to software, businesses are often more concerned with meeting deadlines than building a stable, future-proof product. Launching versions of your software into production sooner than your technical team is comfortable with could result in costly retrofits and years of usability being shaved off down the road.

So what does it take to keep your software secure, maintainable, and flexible over the long term? Let’s consider nine common strategies that you and your technical team should be aligned on to get the best possible value for your investment.

1.  Accurately Defining Business Requirements for Software Development

A good way to fail is by making the wrong product for your business. This seems intuitive, but software (even a simple system) is very complicated, and it needs to serve multiple stakeholders at a company. It is all too common for a high-level executive to request software with features that aren’t actually useful to the mid-level managers and end users. So, making software becomes an exercise in communication.

The first step is to accurately describe the right product for all the business stakeholders. Often this can be done with a few well-timed conversations and emails.

The next step is to describe the right product to the development team. You wouldn’t expect a construction crew to construct a building from an artist’s sketch. The crew would need highly detailed blueprints. But in the world of software, many businesses provide only a rough sketch to the development team, perhaps a powerpoint and some wireframes. This is a recipe for confusing, frustrating, unnecessary software. Programmers need precise, thoughtfully defined requirements with clear examples of what you are looking for.[1]

2. Enhancing the Developer Experience 

We’ve all heard of user experience and why considering it is important. Developers are a subset of your users—they’re simply working under the hood. They need quality tools and methods that work well in order to yield faster, more stable results. (Help me help you.)

This includes a robust development mode for testing the software before deployment, a well-thought-out strategy to avoid “squirreling” (more on this later), and positive morale.

If the developer experience is pleasant, your software will be made faster, and there will be more interest in creating quality versions of that software. Changes to the software can be made more efficiently, and new developers can be onboarded very quickly.

Giving your developers tools and processes that improve their experience will streamline the entire process from beginning to end. 

3. Avoid Task Switching or Context Switching 

Extensive research shows that frequent task switching—at times referred to as squirreling—is detrimental to our productivity, increases the risk of error, and demands a high cognitive load.

Frequently switching gears midstream will tank the velocity of any team, but this is especially true for programmers. When writing code, they can be working on a train of thought that spans several days. When this is interrupted with a request to make something else, it leaves loose ends in the code base that have to be finished later. A piece of code that was 8 hours away from completion may now be 24 hours away from completion when it is revisited if the original train of thought is lost or interrupted.

It is a red flag if your requests for changes encounter resistance from your development team. Usually this is a sign of too many tasks in process and too few completed (which means the code has been deployed and in the hands of users).

Having a clear product vision will prevent the interruption of a current workflow with a new/different/side workflow. [2]

4. Implementing Infrastructure as Code 

Your staging, quality assurance, and production environments should all be identical. The only way to keep your servers truly identical is by writing a script that can be run by your cloud provider to automatically reprovision your server. This is called “infrastructure as code,” and it is manageable, scalable, and predictable.

The parameters and settings of your system are written and provided to any platform as a complete package, not requiring any set up or manual adjustment. This methodology is like a series of rubber stamps that can be used over and over again, yielding the same results every time. This avoids the dreaded “pet” server that requires special handling and the manual expertise of a specific technician. It avoids the “snowflake” server that is unique and delicate, impossible to replicate later if your business needs to grow.

Using infrastructure as code turns your servers into cattle rather than pets. They are all treated the same and offer consistency. Instead of manually setting up specific servers (treating them like pets), you can write a script and run it whenever you need to spin cloud services up or down (treating them like cattle). You can scale up in seconds, and if you find that you no longer require all the resources you formerly did, it takes only moments to scale down.

All the most popular cloud service providers—Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP), and others—support all the automation tools necessary to provision your infrastructure as code. The flexibility offered by infrastructure as code is key to getting the best ROI out of your system.

5. Emphasizing Peer Code Review

Every newly constructed building goes through many inspection processes, not because the workers are unqualified or untrustworthy, but because there is always something to gain from the insight of other experts.

Having new code reviewed by senior level developers before it’s checked into the master code repository will not only eliminate problems down the line but will create a more consistent code base and contribute to the training and sharing of knowledge with junior level developers. All of your developers will have a better understanding of the code as a whole, avoiding single experts in small areas.

The reality is that programmers can and do transition in and out of companies. If one was working in a non-peer-reviewed vacuum and transitioned to another job, this could leave a question mark in the code that would require time and resources to figure out and integrate with the whole.

Knowledge sharing makes for a healthy, productive company culture, and that in turn will produce a better product. 

6. Investing in Delivery Automation for Efficient Deployments

Newly launched software, regular updates, and new features all travel along an automated pipeline to the end user.

We are all familiar with software updates to our smartphones. These updates are downloaded and installed automatically. Imagine, instead, if these updates were emailed to you from an employee at Apple or Google. Or if you had to make an appointment for a technician to come to your house and update your phone.

This sounds ludicrous, but many companies struggle with the fragile process of delivering software manually rather than having it automatically deployed. Delivery automation allows developers to roll out needed code changes quickly and efficiently.

It’s also very important that these code releases not be tied to feature releases. This is possible by building Feature Flags into your system, which will allow you to turn certain functionality on or off (or versions of each functionality) without deploying new code. This allows you to test new features in production and immediately rollback or kill any feature without deploying new code.

Small patches may need to go out immediately, but if they are tied to an unfinished feature, you will have two bad options: delay an important update, or release a feature that may break everything. Automating the delivery can also allow new features to be released gradually, perhaps to a small number of users within the organization, before releasing them to everyone.

Keeping code releases separate from feature releases and automating both create stability while simultaneously speeding up the responsiveness of your development team.

7. Adopting Test Automation for QA

Testing your code before every deployment mitigates risk and increases quality control, so it’s a matter of course that you would want to do so. Rather than hiring people to simply test it manually, smaller pieces of software can be run alongside the main software, testing as it is built and deployed automatically.

Imagine if the plumber working on your house had little robots following him around, jumping down the pipes and checking for leaks as he worked the whole time. Not only would he be alerted to issues long before they could bother you, but he would also be able to move more quickly through his work with greater confidence.

Automated tests being run in a pipeline allow quality metrics in the code to be visible to your entire team, and quality control becomes part of your assembly line. Having rock solid testing requires building a strategy with your development team from the beginning.

Healthy code is easy to test. But if the tests seem fragile, if they break all the time or are often ignored, this is a red flag that the tests are not high value and are not testing the right things. The better the code, the easier it is to test.

Having test automation keeps the entire team alert and accountable for writing good healthy code—not just the developers.

8. Ensuring Regular Maintenance and Upgrades

Software is always changing. All programs ride on the shoulders of other programs, making it possible to build incredibly sophisticated systems. Parts within the system are constantly being updated, defended against malware, and improved.

To keep your software running properly, it has to keep up with the larger ecosystem. It has to be maintained.

If you made the investment of building a house, you wouldn’t later refuse to clean the gutters or treat for termites simply because the house was finished. In the same way that treating your house for termites is cheaper than having your woodwork replaced, keeping your software current will defray costs down the road. The cost of staying current is lower than the cost of updating infrequently after several generations.

If you hear that the updates are too costly or take too much time, this is a red flag. This is tech debt that needs to be paid off.

All code needs to be patched and kept up to date. Operating systems need to be kept up to date. Delivery platforms such as the App Store have guidelines that require consistent updating to the degree that they will remove an app from the store if it is not kept up to date.

Proactively maintaining your software is safer and more cost efficient for you and your users.

9. Incorporating Built-in Security Measures

You build trust with your users. If you violate that trust, you may have legal repercussions, loss of brand trust, and financial implications. Since security is such a high priority, it should be built directly into your software as part of the development process.

Make sure your developers are familiar with secure coding practices. Have the code evaluated from a security standpoint. Building in security from the ground up will make your software stronger and therefore last longer.

Imagine you finished constructing your home, only to realize that the electrical wires pose a fire hazard. To be safe, you would need to rip them out and start over, which would obviously be extremely costly. It is always better to design with security in mind from the very beginning.

Creating Software that Stands the Test of Time

Each of these topics easily merits an entire article of its own, but if you can talk about them with some fluency to your team, your product will end up being relevant and useful. Being on the lookout for traits and habits that could harm or hamper your system as it develops over the years will keep it robust and stable. And finally, giving your developers the tools they need and the time to follow these healthy practices will keep your system fresh and innovative.

While these approaches require time, commitment, and effort, the result will be software that can easily last for fifteen years and will yield a significant return on your investment.

If you’re committed to building enduring software, we’d love to hear from you. Schedule a consultation to discuss how our strategic approach can ensure that your software doesn’t just launch—it thrives for years to come.

[1]  BDD or Behavior Driven Development is an approach to software development that encourages a strong focus on the behavior of the system as perceived by its users. For more on this, see Domain Driven Design with BDD by Dave Farley

[2]  For more on developing a strategy for starting less and completing more see "Why Limit WIP? We're Drowning in Work" by Jim Benson Why Limit WIP: We are Drowning in Work (MemeMachine Series): Benson, Jim: 9780989081238: Amazon.com