Refactoring vs Rewriting Part 3: Convincing The Boss
According to Stack Overflow's 2024 Developer Survey, the amount of technical debt is the top frustration for software developers in their work, with over 62% of developers feeling its impact. In the survey, almost all professional developers agree that improving quality of code provides the most satisfaction at work. To navigate these challenges, mastering code improvement techniques is key: Refactorings and rewrites require the right technical skills, strategy and the buy in from management. This blog series will explore the key aspects every developer should know, offering practical tips and tricks for improvement.
In the first two blog posts about "Refactoring vs. Rewriting," we explored the basics needed to start a refactoring or a rewrite. We discovered tools that help us understand what actually needs code improvements. Then, we found out about common pitfalls and how to avoid them in the planning phase of such a cleanup.
So, is that all we need to consider? Well, no. When working for a company, there's almost always a boss. One of these guys up there needs to pay our salaries and be on board with the additional work we create.
How would you approach your boss, the management, or the CEO to get their approval? Especially with larger rewrites that take weeks or even months, this will be a hot topic for them, and you cannot ignore their voice.
If you're not a junior in your area anymore and hold a higher position, it's expected that you can communicate this well. Ignoring this part can be fatal for your engineering career.
I remember when I started a new position as a software engineer in a company with a web-based product. New stack, new people, new coding style. Some code was really hard to read, to say the least. Adding a simple button was a nightmare and took ages due to dependencies and weird event chain wiring. Outdated libraries were everywhere. We were using Ruby On Rails on the backend and Ember.js for frontend development. Both frameworks were used in a very hacky way. There were monkey patches everywhere to keep things going, bad test coverage, and outdated libraries. GitHub was warning us about several security risks. Upgrading the already unsupported frameworks was almost impossible because of dependencies. It was a tough start aiming for good coding principles in the code base you work with daily.
But we were keen to clean it up, make it work, because we were sick and tired of working with this clunky codebase and constant alerts. With the ambition and maybe "the dream" of a shiny, future-proof, and up-to-date, secure technology future for our app, working with the newest major versions of the frameworks, we made a plan for how we could approach this. Very quickly, the technical questions were answered, and we had to convince the boss now.
The way to the management table was short. We worked in an open office setup, so we quickly chatted and asked for some time in the meeting room.
We prepared our technical and personal issues with the existing code base. What a mess there was, so we were very convinced that they would just pass through our wishlist. In an emotionally charged atmosphere, we tried selling our points:
Boom, they got it, right? No! They did not get it at all. Are they serious? All valid points from our viewpoint, so what did we do wrong?
Management was very confused and non-understanding, almost felt attacked by our arguments. What they heard was completely different from what we wanted to tell them. Their response was more like:
All in all a total disaster not leading to a fact-based discussion.
From management's perspective, the decision to refactor or rewrite a software application requires a comprehensive analysis that balances technological needs with strategic business objectives, financial considerations, and risk management. Our proposal needs to articulate not only the technical benefits but also how the overhaul serves to advance the company's strategic goals, manages risks effectively, and offers a clear and compelling return on investment.
Successful advocacy often involves presenting a well-rounded business case that addresses these multifaceted concerns. And this is what we were missing completely. We were just focused on our needs and good craftsmanship.
But if you can't present this, even the best technical concept is useless. You can think of it as a pitch to an investor, like in the TV series Shark Tank. The backers, i.e. the decision-makers, are not interested in technical details. They wouldn't even understand them, so save yourself the work and save them the time. They are interested in figures and perspectives. The risk has to be calculable and the return tempting, otherwise, it's "I'm out."
A vague cost analysis of "a few weeks" alone will not be enough in this case! More effort is needed as preparation. So what can we do?
Here is another example taken from our career course: Jeff, a Senior Software Developer, pitches a rewrite to senior management. Check out the management reaction:
Gut feelings and emotions don't sell well in management. Numbers, strategies, and evidence would have been better. The smaller the project, the easier it is to generate this information. For bigger projects, this becomes a challenge.
Here is a list of topics and questions you should have on the radar before going to management. It's a lot of questions, but when you can answer most of them, you will be well prepared:
That is quite a lot, but that's okay. Just think of the risk and the financial figures that play a role in such decisions. Management needs certainty and is naturally interested in finding the best possible solution for the company.
Recall Jeff's pitch disaster video? Check out this improved version from our career course:
In conclusion, getting management buy-in for a refactoring or rewriting project requires much more than just technical arguments and personal frustrations. It demands a strategic approach that aligns with the company's business objectives and provides a clear, compelling case for the proposed changes. You need to show management how the project will drive value, mitigate risks, and ultimately support the company's growth and competitive edge.
By preparing thoroughly and addressing the concerns of management with solid data, business alignment, and strategic benefits, you can turn a potentially disastrous pitch into a winning proposal. Think like an investor presenting on Shark Tank: make the risks calculable, the returns enticing, and ensure your vision aligns with the company's goals.
So, before heading to the meeting room, arm yourself with comprehensive answers to the critical questions outlined above. Show management the broader picture, and you'll have a much better chance of securing their support for your project.
Good luck with your pitch, and remember, it's not just about clean code; it's about driving the business forward.
PS: In our career course "The Tech Career Playbook - 7 Rules Beyond Code" we address the topic of technical debt in more detail, explaining the ins and outs to build a solid business case for management and ensuring the success of your proposal.
Utterskills - We are an e-learning academy for IT-professionals and provide micro learning video courses for all relevant topics beyond code in IT-careers. Did you like this article? Then you're gonna love our videos! Why don't you give it a try? It's free!
TRY FOR FREE