The Non-Tech Manager's Guide to (Legacy) Software Development

I've written several articles on the technical sides of legacy code and technical debt. But now, let's focus on the emotional side, the human factor. I've touched on this previously, but would like to expand on it a bit further. What Frustration Can Lead To Working with legacy code can be frustrating. Especially if there is not enough room to improve it. Or if there is room, but the team can't seem to succeed in improving, for whatever reason. Frustration that is left unaddressed for too long leads to all kinds of bad things. Developers can start…

So you've decided to do something about that piece of legacy code that is taking too much of your team's time. Then you should be aware of the strangler pattern. Your Options When dealing with a piece of legacy code, you basically have three options: do nothingrefactorrewrite I've written about the first option, when it's OK not to touch the legacy software. I've also written a lot about refactoring and specifically about the choice between refactoring or rewriting. If you've been following this blog, you know I prefer a refactor. But sometimes, a rewrite is necesary. Like…

Are you convinced your team should spend time paying off technical debt, but you can't get upper management on board? Here are some ideas that might help. Collect Numbers Upper management or the board of directors work a lot with numbers. Their job isn't always easy: the people they manage are most often not happy with the resources they get. They usually want more so that they can achieve more. But C-level managers need to take all groups, interests, budgets and future plans into account. So when you think they're taking a bad decision for not paying…

There are many ways of categorizing technical debt. Here is just one way. I divide technical debt along two axes: intentional vs unintentional and known vs unknown. And I'll briefly mention a fifth category that doesn't fit well with these axes. Intentional Technical Debt Technical debt can be a conscious decision, like a real loan. It can make sense to incur technical debt. For example, if you need to find out if a certain feature will be used and is worth developing further. In that case, you might want to implement a minimal version quickly, to measure…

So you have a legacy application with quite some technical debt? But you've started turning the ship around and the situation is improving, right? If you're planning on increasing the release cadence, you'd better start monitoring your application. What Is Monitoring? Monitoring is the practice of setting up an automated system that keeps an eye on the health of your application. This ranges from error rates over response codes (for web applications) to performance metrics. Basically any metric that can be measured and is relevant for you. Why Should I Monitor? Software is complicated and you can…

I've already written about why you need automated tests, but let's take a step back. Why do you even need to test legacy software at all? It's running fine isn't it? Until it isn't. Legacy Software Is Important First and foremost, many legacy software systems are important to the business. They often actively bring in revenue. So their stability and reliable operation has real business value. Therefor, testing these systems has business value. We want to verify that the system does what it is expected to do and performs as desired. Legacy Software Is Alive Most legacy…

I want to add one more thought to my previous post on how to achieve weekly (or faster) releases. It's about the difference between timed releases and scoped releases. A Little Background You can read my previous post, but to summarize: a client of mine went from irregular releases that had a specific scope to weekly releases without a predefined scope. Whichever feature or change is done makes it into the release. If something isn't finished, it's not a big deal because there is a new release next week. Scoped Releases A scoped release is simply where…

A client of mine started out with random ad-hoc releases with frequent regression bugs and moved successfully towards weekly releases. Here are the main points that helped us achieve this. The Previous Situation Previously, a developer would finish some feature and mark the issue or ticket as "Done." But it was usually a mystery when the feature would make it to the next stage, let alone production. This was mildly frustrating because the developer wouldn't know for sure if the feature worked as desired. When it was time to deploy to a stage, the project manager would…

Backward compatibility in software development is an important concept that is often overlooked, especially in legacy systems. This leads to stressful software updates and regression bugs. But it's usually not so difficult to avoid these horror scenarios. What If you're unfamiliar with the concept, backward compatibility means making sure a new version of software keeps working with the current version of an external system. Backward compatibility is important when you're going to update your software. In this day and age, it's very likely that your software integrates with other systems like a database or a service from…

Are you afraid of your next software release? Were the previous releases plagued by bugs? Even for features that worked previously? There are ways to avoid this, but they're often counter-intuitive. Let's look at what causes these bugs, and how we can break out of this destructive cycle. Regression Bugs What you're experiencing are regression bugs. These are bugs in pieces of the software that weren't there previously. The cause can be anything from code that has been changed to a system upgrade. If this is happening continuously, this is very frustrating for everyone involved: users, developers…