Back to the future — part 3: how to convince “the business”
Legacy software stories
Welcome to the third part of our series on legacy software and how to deal with it. In case you’ve missed it, in part 1 we covered the definitions, typical problems and discussed the “rewrite it all” strategy, while in part 2 we continued with a more gentle approach of introducing new technologies to an ageing architecture layer by layer. In the future parts we will try to show other approaches that you can take and we will share the outcomes of applying them to the projects we know.
All this has been written about from the perspective of the technical team / technical person working on the legacy system. So the perspective can be biased.
Today we’d like to address the fundamental question of refactoring: “how to convince the business / the management / the leaders / the bosses / the owners (you name it…) that we should do it?”. The question indeed is fundamental, since whatever you will try to do will cost some money. And if there is a cost involved, there is someone who will be paying it! Consequently, you need to learn how to sell your brilliant refactoring idea!
Prerequisite
At the beginning we are assuming that: a) you have legacy software; b) you defined the specific problems you are going to solve in it and c) you have an idea for a solution. If you fail at any of these 3 points — go back, and do your homework first.
If you have all this in place, you need to think — who you will be addressing with your message. You’d use one strategy to talk to a decision maker who is very technical and knows the interiors of the system in question, and a different one to a business person who knows very little about the technology, coding, tech stacks etc.
Is it my problem or yours … or ours?
Finally it is time for the first tough question of the day. Looking at the problems you’ve identified and the people you are going to be talking you, you should verify if your problems are also their problems! At first it may seem obvious, but it is not.
Example 1. One of the commonly observed problems in development teams working with legacy code is poor tooling. You can’t use your fancy, new build script / CI / static code analysis / IDE / editor / cloud based reviewing platform / git / or whatever you’d like, because of X, Y and Z. It’s painful and hateful for the devs. And obviously it is a real technical problem! But is it really a problem for that business manager who is paying for the changes in the system? Is it really a problem for that board member taking care of the maintenance budget of the production environment? Go ahead and tell them: “you need to invest, because we can’t use git!” and see what happens. Most probably it will drive them crazy mad! You need to work harder to express the problem you have in the language of the person you talk to. How? We will go back to this in a moment.
Example 2. Your dev team is fed up working with a framework which is 15 years old. All the guys you have in the team spend time reading Medium posts on new stuff, yet they have to code in Apache Struts or ASP.NET Web Forms. The system you work on is making money and works as requested. It just sucks to work with. And this is your problem. Is it also a problem of the business owner or manager? If you ask her or him directly — the answer will most likely be “no”. Yet, if we go further the line and discuss motivation, ability to attract new people, creativity, etc… the perception may be different. So again, depending on the language you use to communicate your problem, you may either make your boss angry or make him or her pay for your brilliant ideas.
Example 3. The architecture or your system is message-driven. You have many modules / apps and a common message bus. The problem you see is that the message bus is super ugly. The smallest message it can pass is 64 kB of embedded XML envelops encoded in a strange binary marshalling format. The solution lacks many features of modern, scalable, distributed integration solutions. Everyone in the team feels it is slow. So you tell it to your boss… slow integration layer is definitively his/her problem, right? Well, it depends. If you are able to show specific data (numbers!) and relate it to business value, you may be right. But if you base it only on feelings or prejudices, or you will concentrate on XMLs, binary formats, multicasts or UDPs … the perception can be strictly different (in the wrong way).
Summing up, the case here is that your message should express the problem in a clear way which is easy to understand by the listener and which corresponds to their values, priorities, and tasks. You don’t have to explain every technical term in detail for this! You need to pick topics, which are clearly related to the business. Below, we present a few communication tools that you can use to present your case this way.
Show me the numbers!
Common challenge in communicating technical problems relates to the data. In most cases you should prepare specific data to back your points. If your strategy is addressing development velocity you should measure or estimate the time the team is wasting on doing stupid things (due to legacy). If you are attacking systems performance — again, show the history of specific performance measurements with predictions for the near future. Instead of giving general terms, give specific numbers and concrete examples! So instead of saying “the system is becoming very slow” say “action A in the system is 23% slower when compared to a similar month of the previous year”. Instead of saying “the devs are wasting time on unnecessary tasks” say “in last 4 sprints, we wasted 74 man-hours on fighting with broken test environments due to X, Y, Z”. Instead of saying “these problems keep repeating over and over again” say “the problem P happened 27 times in the last month, and we expect this number to be growing 30% each month”.
If you are going to be presenting your case on a meeting, gather the data you have on plots and small tables. Yet, be very careful. You do not want to overwhelm your audience. Try to calculate a few metrics beforehand and then pick the ones which are most directly connected to your point, easy to understand and that correspond to the language of your audience (i.e. if anything can be expressed in money — use it!).
Saving costs or generating value?
Eventually, every problem you will be discussing will relate to money (sorry, but this is how it is). First of all, solving problems brings costs. This is obvious. What is not obvious is what the gain of solving a specific problem will be!
There are two sides that we can be discussing of such a gain: making savings or generating added value. Typically the first way is more straightforward in thinking. If the development takes too much time and you have an idea on how to cut this time, you will in turn save on the development costs. If the performance of the system drops and you know how to stop it, you will be saving on infrastructure, maintenance and so on. If license fees for legacy, proprietary technologies are killing you and you know a way how to replace that with cheaper alternatives — you are obviously limiting the cost. BUT!
In many of these cases you can think more creatively and look at the potential new value that may be generated. Saving costs is cool, but making something new — making new money (!) is much cooler!
So maybe in your case you can relate to the potential benefits of introducing the change, by showing what new things will become possible and how they can pay back. Maybe a new tech stack will allow you to plug-in a modern AI-based analytics and help in marketing. Maybe the increased development velocity will finally allow to implement a new feature X that the users are willing to pay more. Maybe by replacing the integration layer you will be able to speed up the business processes and offer a premium service for the customer (super fast deliveries, higher quality, whatever). Maybe due to a new API interface, you will finally be able to unlock the possibility to launch a mobile app for your business and enter new market segment.
This line of thinking is harder to go along! But going there will most likely pay back to, since business people will definitively understand “new money” message!
Promise or over-promise?
When discussing the outcome of your proposal — either in savings or added value you make a kind of promise (intentionally or unintentionally). When you say, that we need to change the tech stack because the development is too slow — implicitly you promise, that indeed with the new technology the development will get faster. So no matter what you say, at some point you’ll be making promises, which is good! But you need to be careful. You want to promise something valuable in order to convince your audience that it is worth investing in your idea. But you definitively do not want to overpromise!
What is overpromising? Promising things that are too good to be true and/or taking for granted things that you are not sure about. If you make a promise you should believe it yourself and afterwards you should do whatever you can to live up to the promises.
Typically developers tend to underestimate the effort and overestimate the gains. Especially when they really want something to happen. You want to get rid of this old Java-based system because it is so painful to work with and you fell the pain. So what you’ll do? Tell them, that it is super easy to replace it and that the new version will be much, much, much better.
Unfortunately this is a dead end. If you push a non realistic message too hard people will stop trusting you! And if that happens, you won’t be able to change anything. So make your promises — but keep them realistic and detailed enough so that people believe them.
Plan or a set of ideas
Very often we have great ideas to solve real problems, that would bring a lot of benefits. But an idea is not enough to solve the problem. The idea needs details and execution. And this turns ideas to plans. If are aiming for a big investment to happen to your legacy code base you need to present a plan not an idea. You need to tell how you are going to implement your idea, you need to tell who will do it, how long it will take and what you will do when some risks will materialize (which means you need to define risks). If you don’t do it — again people will be less likely to trust you and you really need their trust.
Summary
Final takeaway! If you want to do something great with a system which is not that great, you need to work really hard to formulate a right message to the money owners! You need to draw the problem, define your solution, show the value that it brings — deliver a trustworthy promises, which are not overblown and put it all in a clear plan. Moreover this plan needs to be written in a language that your audience understands. If they are non-technical, do teach them fundamentals of computer science — speak about business. If they are technical — keep your message more technical, but still try to look at the things they care about and the things they get credit for in their jobs.
If you do all the things right — you are likely to build a strong case and finally start bringing your ageing system back to the future!
This article has been co-authored by Łukasz Drzewiecki.
We are JIT Solutions and we can help you with the development of your software! Just let us know: hello@jitsolutions.pl.
