#44 Fallacy of Sunken Code

This is post #44 of my #365 day series.
Photo by Tengyart on Unsplash

“We should plan to rewrite 80% of the code anyways.” Oy. Having spent the entire day trying to shoehorn in bad code into a new build, I’ve really got to get this off my chest. There’s no excuse for bad code. I know, I know. “Let’s just get the MVP done Tony.” Listen, I get it. If you need to prototype something, that’s fine. Just get the thoughts out there. That said, there’s always UI/UX prototyping tools out there to show your thoughts. The excuse I constantly hear for not doing something in a scalable manner is unacceptable.

Why is it bad? Not addressing the massive issue that it is a waste of time and resources, but it creates so many issues down the line. I’ve seen it in the legal field as well where a person is too lazy to rewrite a provision the correct way and instead adds a line to it (hence my bias against the usage of the phrase “notwithstanding anything to the contrary herein”). You’re kicking the can down the road and you or someone else on the team will 100% pay for it. In contracts, it makes it that much more difficult to interpret the contract (not to mention making it a living hell for us folks trying to develop AI tooling to interpret contracts).

Now I’m not saying you need to write unit tests for every single function that you write. I’m saying that you spend the time to think, “Is this code that I’m adding going to bite me or someone on my team in the butt sometime later?” Honestly, some of this is my fault. I’ll write code that I expect is very straight forward to scale out. Heck, I get people complaining about how much I comment in my code (my apologies, it’s my lawyer tendencies taking over). What I didn’t anticipate was, laziness and lack of commitment to the quality of the code. Instead of spending an extra half hour thinking about how to refactor other code to make the new feature or code scalable, they’ll just layer on garbage code.

In both investing and the startup community, there’s this pervasive concept of “I’ll fix it later” that needs to stop. Obviously we’re not saving lives with the code we’re writing, but what about healthcare tech? It worries me that this same consideration is being used in other industries where things can’t fail.

So what’s the solution? Well, I have one proposal, add a permanent field to git commits that require that the committer rank the code quality of their commit. This gives us an objective way to track what programmers believe is high quality code. Large code commit templates make life much more difficult to get people to fill out, and doesn’t provide an objective way for us to track what people believe is actually good code. A part of this is getting people to think and commit to what they are putting out their as their work product. It is a bizarre world to operate in where a common theme in engineering is people’s lack of caring about what they are putting out into the world.

--

--

--

CEO / Chief Engineer of HyperDraft, Inc.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Integrate Zapier and Notion — Todoist / Twitter to Notion Database

Docker for Continuous Delivery: The Basics

Benefits of P2E and the Hash Warfare

PMP 2021 and beyond: why you should stop worrying and learn to love the change

Hotbit supports the upcoming hardfork of GRIN😊

How to check execution time of Python scripts ?

My Mastery Journey

Mastery of “Scrum-Mastery”

What are the main skills that good Scrum Master should have?

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Tony Thai

Tony Thai

CEO / Chief Engineer of HyperDraft, Inc.

More from Medium

#12 Be curious, not judgmental

How do you find story? 2 Questions you should ask yourself to uncover your business’ why.

Take Control Of Your Life