This is post #44 of my #365 day series.“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.
