Don’t be a Monday Morning Quarterback when working with Legacy Projects
September 29, 2022
Estimated time reading: 5 minutes
Football season has returned, and some of us are back to our old habits. You know who you are! You’re the one whose team was crushed Sunday night and is now full of opinions. So you’ll gather with like-minded individuals at the water cooler or WhatsApp group and start ripping into your team’s players.
The QB should have done this! The coach should have done that! Why didn’t they do this play? How could he miss that pass? How did he miss that tackle he was right there?!
This is usually when you and the other “top-tier coaches” get bolder.
Well, if I were the QB I would have done this play! If I were the coach I would have told them to do this! No way would I have missed that pass! That tackle was so easy my 5-year-old kid could have done it!
This isn’t exclusive to football: hockey, baseball, basketball – every professional sport. We think that for some reason that under the exact same conditions, we could have done a better job than professionals who train their whole lives.
And you may be right. In hindsight, it could be true that they would have probably ground the other team into dust if they did all those things. But what is often forgotten is that at that moment, you have one set of ultra-competitive individuals in a hyper-competitive environment against another set of ultra-competitive individuals. So while hindsight might be the best teacher, these men and women have simply done the best they could given the circumstances.
The same can be said for most software engineers and legacy projects.
So why do so many Software Engineers, after getting a new job or starting a new project, tend to fall into the same patterns as Monday Morning Quarterbacks after looking at others’ work? We see poorly written legacy code, badly designed architecture or hastily written technical documentation and assume that if it was us, we would 100% have done a better job.
Why did they design their objects/classes like this? This isn’t Clean Code at all. Did they skip that class in kindergarten? They are not using the features of the language properly! I can’t believe they used this outdated library! What were they thinking?!
And just like a Monday Morning Quarterback, you gather with your current team and start boldly proclaiming,
This is the architecture I would have used! This is how I would have optimized this! I would not have rushed and done this properly! My documentation would have looked like this! We would have never gathered all this tech debt!
The truth is, exactly like a professional sports team, a group of skilled individuals have simply done their best given their abilities, limitations, and circumstances at that moment. The reality is that you simply have no idea what those circumstances were. Maybe that team was under the gun the entire time trying to meet an impossible deadline. Or they were understaffed and struggling. Or that the team lacked the proper skills and training. And maybe, someone’s significant other broke up with them, or their kid got suspended from school and writing Clean Code was simply the furthest thing from their mind. The point is that we don’t know and likely never will. There is no point in running through a bunch of assumptions and imaginary scenarios; getting frustrated because now you are stuck working with unworkable code.
Sit down, take a breath and start figuring out what you will need to do to improve your current situation; advise what the best course of action is and huddle with your team to see how you can avoid repeating the mistakes of your predecessors.
And just in case you were wondering: after you’ve worked the unworkable code and your new codebase is a pristine example of the pinnacle of software engineering that will be taught in computer science programs for a hundred years – someone will see it and boldly proclaim, “I could have done it better.”
This blog post was originally published on Vitaliy’s Medium.
Subscribe to Our Newsletter
Join the Thoughtworks newsletter list to receive curated content that exemplifies our Product thinking approach.
Related Posts
Fri Feb 3
Thoughtworker Spotlight: Justine Lachapelle
Justine Lachapelle is a world traveller, and we couldn't be happier her travels have taken her to us (likely her favourite product helped with that). But, whatever she is doing, there is one constant in Justine's life - people. When she's not earning more stamps in her passport, this health enthusiast constantly stays active, from hiking to snowboarding and everything in between. As Head of People in Canada, you can find her working with the People team, constantly ideating, implementing, and supporting new initiatives and programs like remote-first work and work abroad programs for Thoughtworkers across Canada. Did we give you enough information to guess her favourite product? We didn't think so either. But you can click below to find out in this week's Thoughtworker Spotlight.
Fri Jan 20
Thoughtworker Spotlight: Jason Zheng
Who better than Jason Zheng to jazz (or should we say, Jepsen, as in Carly Rae) us up this January? Whether he's delivering product impact to our clients or coaching and mentoring future generations of engineers, his skill, dedication and passion always shine. When he's not busy wearing iconic nature landmarks shirts (or looking for new ones to add to his collections), you'll find Jason cooking up new recipes, gaming with friends, or savouring in the runner's high. Now, can you guess what his favourite product is? Here's a hint: he can spend hours with it and has not parted with them even after discontinuation, buying multiple pairs as backup.