When a team member first hears me say, “It is more important to be consistent than to be correct”, in order to settle a debate about which fork in the road is the one best traveled, their reaction is the same. An incredulous look, as they might gawk at a fool; though perhaps I am.
The clever, fresh-from-school students are the ones that do the worst in this exercise and find great provocation with doing something in a way that is obviously the wrong way to do it. I understand and empathise; after all they have just spent 20-something years in an institution that very much lives on the very notion of correct and incorrect, and here’s this chap that says it is irrelevant in order to develop software. It is OK: the friction is healthy and helps me learn new things, too.
At the face of it, though, it is true, yet it is not the face that is of import. Being consistent means not repeating yourself. Being consistent means fixing problems at the core. Being consistent means maintaining discipline. Consistency means standing ankle deep in code and accepting it for what it is. Being consistent is what most of the good development practices are advocating on a philosophical level. They help us be consistent because we are quite frankly very bad at it. It is counter-intuitive that the incorrect path is the correct one, but it is simply a matter of scope. It depends if you opt for the long haul or are in it for the short term; instant versus delayed gratification.
A common, simple scenario might be:
“Do we use the method from another package that works but isn’t very elegant, not very nice and kind of buggy, or do we implement a new method that’s perfectly SOLID?”
If the method that makes you wrinkle your nose a bit is already in use — use it. Being consistent here means it’s a lot easier to fix the problem down the line. If you have the slack in your project to implement a “new method”, you damn well have the slack to write tests for the offending method and re-implement it. This is your job, and you are making the world a better place for all your colleagues by doing so. Every piece of the system that relies on this code will be improved by your work. Your work impacts and benefits everyone, though they might not know it. In this realm, you are the Batman.
Though when their jaws clench a bit, there is sympathy and understanding within me. Greenfield programming is more fun. No one wants to start their day deciphering someone else’s shit only to spend the remainder of the day fixing it. But the Batman does not complain about the mess others made, s/he just makes it better for everyone.
Opt for consistency over correctness to consolidate your code base. If you try to greenfield on a microscale you succumb to never aspire the Nirvana of Code — Clean Code. The paradox is of course to make a strong case for that incorrect is actually more correct than to be correct. It is hard to accept that what is incorrect today might be correct in the future.
Yes, there are bugs in that code. No, it doesn’t do exactly what we want. No, it is not the most efficient way to sort through a list of items. Yes, you are absolutely correct, yet use the incorrect option anyway.
This is the price we pay in order to refuse to let our code base grow more than absolutely necessary. Have you ever heard of a legacy system that wasn’t horribly large and cumbersome? A legacy system with a handful thousand lines of code spread over a couple of classes? No. The very definition of a legacy system is an impenetrable hulk of a beast. Over time our system might evolve into such a creature, but we must refuse it the opportunity at every turn, and being extremely consistent is a tool to accomplish that.
With dependency management tools it is very easy to resort to pull in libraries that accomplish the things we want, and I encourage to do this with discipline. You might prefer the Guava library over the one that is already embedded in the project. If you opt to add the library anyway when there exists a way, however cumbersome in comparison, to accomplish it with what you have you are the Bane of the code.
I hope there is a Batman lurking the shadows of your code who takes you down.