The Pragmatic Avoid The Mediocre
One of the big time wasters in software programming is having to deal with mediocre implementations that, although well written and documented, are poorly thought through resulting in bad abstractions and code smells all over the place.
Think of the parts of your codebase that you feel like you are stuck with them. Neither too bad to need a refactor nor good enough to not give you any headaches. The kind of abstractions that helps you in some ways but leaks enough to force you to make a few bad decisions. This makes mediocre code spoil what otherwise would have had the potential to be great code.
Two types of behavior lead to this mediocre result. Thinking too far ahead and writing too many abstractions. Creating a whole ORM system, database query builder, deploying a micro services architecture, creating a plugin system among many are huge abstractions that are too big and too complicated to build at the beginning when you don’t even know if you are on the right path. The second one is being short sighted and just making things work for now. Zero thoughts given to data structures, too many parameters for a single function, using too many flags to control the flow or cramming a multi-step process in a single step.
These are a few examples about what decisions lead to mediocre code and hard to maintain implementations that will hinder your ability to adapt to new requirements due to either having to do too much work because of bloat or having to deal with too much complexity because the code is too hard to follow.
One way to avoid these situation is be being pragmatic on both sides of the isle. Do we REALLY need to build an entire ORM framework right now or can I deal with creating a few objects manually for now? Also, can I invest a little more time to understand the problem and find a good solution rather than just making it work now and curse every single time I came even close to this function?
Another way of staying away from mediocre solutions is by not getting sucked into situations like “They made X decision and were successful so we should do the same”. While X decision seems to have worked for others, it might be that is the only decision that can be seen publicly and the other plenty of decisions that supported or were supported by X decision remain private. Attempting to build a 1:1 copy is almost always a recipe for disaster as you can only copy what you can see and not the thinking that went into it.
Striking the right balance between investing too much time or too little time is a fine line that can’t be delegated to anyone else other than the person that is currently working hands on the feature. No other person has more context about the problem than that person. Questioning others implementation or taking a step back and questioning our own work will help in the process of finding the right balance.
Investing some time into finding that balance as close as possible to the right time is worth the trouble of not having to do huge reworks later on in the project when the stakes are higher.