Don’t be a Monday Morning Quarterback when working with Legacy Projects

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.

Vitaliy Kondratiev

Engineering Manager

Vitaliy is an Engineering Manager specializing in Android Development at Connected. He’s worked on small and large teams and has always been looking at joining 0 to 1 projects.

Vitaliy is currently interested in creating and maintaining the ideal developer experience through technological and human perspective.

More Posts