-3

This question maybe borderline with the workplace. Also I apologize if it sounds more like a rant than anything.

We have a legacy code base (million of line of code). No evolution is ever possible, there is always an excuse.

  • Other teams depend of our interface so we don't change them to avoid breaking anything
  • Any change is too big to be developed in a short time frame
  • Any change is too big to be considered "safe" and without impact requiring dedicated validation process

Even if everyone knows that there is a problem and that it has been expressed we're always pilling up features, never having budget to reduce debt or time slot to do high impact change. Of course the more features are being pilled on, the more complicated the code becomes and the slower we can develop the next features not taking account for bugs being discovered by clients.

Also the more bugs there are, the lesser the trust is our team (or more like the IT/dev function). Meaning we're even lesser listened to and it's more difficult to justify wanting to do "purely" technical work.

This situation is not new in the organisation, and it doesn't seems like it will change anytime soon.

How do you cope with the fact that you can't do your work properly due to the situation?

JayZ
  • 827
  • 5
  • 11
  • 1
    Some helpful links: https://understandlegacycode.com/blog/key-points-of-working-effectively-with-legacy-code/ http://www.laputan.org/mud/ Old stuff, but still valid. – πάντα ῥεῖ May 07 '20 at 11:20
  • 1
    It's been argued by some that the ancient world eventually collapsed due to cultural complexity. Businesses often do collapse due to administrative complexity, if the bosses have no regard for keeping systems within the grasp of human intellect. The best answer for an individual developer is simply to get a new job where those problems do not exist. – Steve May 07 '20 at 12:00
  • 2
    Don't do a big, high impact change. Do many small impact, low risk changes as you work (in the "make the hard change easy, then make the easy change" fashion), striving to accumulate them towards an overall design goal - and this is not something to wait for the bosses to approve on, this is about the way you work as a team. They don't tell you how to write code, why should they tell you how to evolve it? You guys figure out what's holding you back, devise a strategy to move incrementally towards a better positon, and take responsibility of it and just do it, while keeping delivering features – Filip Milovanović May 07 '20 at 13:43
  • 1
    @FilipMilovanović Right. This is a strategy Martin Fowler suggests in *Refactoring* - don't tell your boss that you're refactoring. Refactoring is simply part of how you do programming, and it isn't your boss's job to know how to do programming. (Unless that is part of their job) – bdsl May 07 '20 at 14:04

1 Answers1

0

That sounds painful… but also really familiar. You're not alone in this situation, it's actually quite common to feel the company doesn't care about the accumulating Tech Debt.

After all, do customers care about the state of the code? Well I'd say they do, indirectly.

As you mentioned, this codebase is making you slower to add new features and bugs are more and more frequent. That's a problem because you'll hit a tipping point when you won't really be able to move anymore, it will cost too much!

"There's no budget to reduce technical debt" is classic unfortunately. However, there's budget to fix bugs it seems. That sounds paradoxical when you take a step back. The thing is: non-technical people might not correlate the quality of the code with the cost to the company. If you try to sell them some big "refactoring of the codebase", they'll not see the value in that—but they'll see the cost!

Therefore, I usually recommend to people who care to adapt their communication. Speak their language! A few things that proved to work for me:

  1. Measure the impact of quality issues on your work. How many points per Sprint are you doing? Is it going down? How many bugs do you receive/tackle per week? Are they accumulating? Can you translate that into money (consider developers salary). Show management the cost of bad quality.
  2. Use a metric that matters to your company that could be tied to quality. Customers NPS, support First Response Time or your Time To Market… Explain how investing 20% in code quality will have a positive ROI (that is business language to say "it worth it"). So you can clean code and still ship more!
  3. Focus on a quick win first. Present a reasonable plan and back it up with data. Then communicate on success and go for another quick win. People need that to get convinced of the actual benefits. E.g. I proved front-end devs were waiting 1 minute between each change to see the results. I proposed to spend 3 days on making that down to 30s, making developers waste less time (~30s / dev / change). That time invested only took a few days to have a positive ROI = clear win.

Finally, I'd recommend to watch this great talk from J.B. Rainsberger: The Economics of Software Design. It's a good complement to help you convince non-technical people on the benefits of that kind of work.

I wish you the best. I'm sure you can manage to get some quick wins first. This won't be solved overnight, but if you can progressively turn the approach you'll be working in a more desirable environment with a better mindset towards Legacy Code. And you'll feel less frustrated!

Let me know if I can help you further, I'd be happy to help =)

nicoespeon
  • 554
  • 3
  • 3
  • My issue is that I can't quantify the time gain by improvements. I can't say: "having CI on every branch instead of only Master will economize 0.2 man days per month". It will improve quality and it will sometimes economize time but it's not really quantifiable. Also, I feel there's so much to do that there is not quick win because even what should be quick require approval of 3+ people in different teams. – JayZ May 11 '20 at 07:47
  • Can you quantify the time lost in bug fixing? The evolution of it is interesting, because it would show you're heading to a state where you won't be able to do anything useful for the customer. Since you need approval from many people to do anything, it's indeed critical to come up with the most efficient propositions. Maybe a [Hotspot analysis](https://understandlegacycode.com/blog/focus-refactoring-with-hotspots-analysis/) will help you make a case for the few files that are really critical to fix: the bottlenecks for everyone. – nicoespeon May 11 '20 at 11:42