The opposite of over-engineering is not (necessarily) cowboy coding
There are many types of programmers you may encounter in a team, starting with those who think they know it all and ending with the lone wolves who hate the idea of working with others. Some may spend too much time thinking about unnecessary details and all the backup plans the project does not need while others may ignore every guidance, process or discipline possible. But does this mean they don’t have anything in common?
According to Wikipedia, over-engineering refers to “the designing of a product to be more robust or complicated than is necessary for its application, either (charitably) to ensure sufficient factor of safety, sufficient functionality, or because of design errors.” Meanwhile, cowboy coding occurs when “programmers have autonomy over the development process.”
The lone wolf’s code might be a hot mess, but that does not mean the job is not done; programmers who practice cowboy coding don’t follow any rules, but whatever they do just works. The ones who practice over-engineering tend to take things too seriously and may become over-zealous. The two are not necessarily different, though; there might be some common denominators.
Symptoms of over-engineering
There are at least eight symptoms of over-engineering that Stack Overflow users have noticed:
- Over-engineering occurs when you write code which solves problems you don’t have
- Boredom might lead to over-engineering. When you have too much time on your hands, you might try to polish code that does not need to be polished.
- If you are ahead of other people, you may have a tendency to exaggerate, which may lead to over-engineering.
- If all goes well and some parts of the code are partially completed, but you start wondering “What if this happens?”, you are one step away from over-engineering.
- If you decide to ignore principles because you think you can do better or know better, you are overconfident and over-engineering might be the next step.
- Over-engineering may occur when there is a gap between the complexity of the issue and the ramifications of the solution.
- Over-engineering happens when you try to prioritize tasks but you end up giving too much attention to tasks that don’t actually pose any challenge.
- Are you constantly trying to reinvent the wheel? Nowadays there are so many libraries that it is virtually impossible not to find an answer to your problem without having to spend time reinventing the wheel.
Common denominator between over-engineering and cowboy coding
Rules are meant to be broken, one could argue. Principles could represent a problem not only for those who practice over-engineering on a daily basis but also for cowboy coders; the first group consists of programmers who choose not to follow the rules because they think they are above them and they can do better while the second group takes pride in bending the rules because they think they have found an easier way to solve problems or manage tasks.
Does this mean they have a lot in common? Not necessarily, but this might prove they are not quite at opposite poles.
How to avoid over-engineering
After you’ve seen the symptoms of over-engineering, it’s time to learn how to avoid this habit. Rob Fonseca, Senior Web Developer at teamDigital Promotions, offered a few tips in a LinkedIn post. If you want to avoid over-engineering, you should be able to explain the code you wrote in no more than a minute and your code should be predictable, which means that “similar tasks amongst classes should produce similar output.” For more information, read his post here.
Do you have any personal stories that involve over-engineering? Kindly share your feedback in the comments sections.