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.
Warning: Undefined array key "modal" in /home/customer/www/thoughtworks.dayshiftdigital.com/public_html/wp-content/themes/connected-2021/template-parts/newsletter-modal.php on line 2
Related Posts

Fri Dec 2
Thoughtworker Spotlight: Chris Russo
Endless, boundless, limitless; words to describe Chris Russo’s creativity. As our Content Marketing Manager, he proves every single day that the pen is mightier than the sword. He has inspired so many Thoughtworkers to share their voice and perspectives through our content, that we even created a secret-not-so-secret society for everyone he’s collaborated with known as the 4P (you’ll have to join the team to find out what it stands for!). Besides being a very avid reader, Chris enjoys spending time with his two boys and partner going on hikes, exploring new towns, and cooking up a storm in their kitchen trying new culinary styles.

Thu Dec 1
Global Day of Coderetreat Toronto 2022
Earlier this month, we hosted Global Day of Coderetreat (GDCR) at our Toronto office. After a three-year hiatus, we wanted to re-awaken some of the community enthusiasm when we hosted the event for the first time back in 2019. This year we planned for a larger event which turned out to be a really good thing as we nearly doubled our attendance. And in case you were wodering, this is how we did it.