This guy would fit in well at my previous job where the founder discouraged writing unit tests because “there are too many scenarios to test.”
Like, wtf…
It’s been the hardest thing for me to instill good testing practices in devs. In a function with 23 paths devs usually burnout and only do 9 or 10. Most never consider that making the function smaller is an option.
1 scenario tested is better than 0 tested.
Stroke of genius 🤣🤣🤣
At one point in my life I was working on a massive Android AOSP fork that itself had lots of variants for different downstream devices. Custom drivers, specialty services, etc. Thousands of people were actively working on all parts of it, and it had been around for at least a decade.
There was incredible tooling around onboarding, local dev, testing, PR management, CI/CD, and post-release telemetry. Almost everything was automated. All code was reviewed at least once, and sometimes more for critical components. It was an immediate rejection if there wasn’t sufficient test coverage. Big subsystems took months to architect, build, and deploy.
Nobody got to cowboy things and just push to release. It was much slower than a solo or a few people at a startup. The whole point was consistency and predictability, and you could see why.
One thing that isn’t mentioned regarding consistency is that it makes the code more searchable. When you start on a new issue you can easily find where you should do your work. You’ve maybe never seen this part of the code before, but you know how to find it.
This is impossible with a largely inconsistent code base. Anytime you start with a new issue you have to find a needle in the haystack.
By far the most important thing is consistency
This is not true. The most important thing is correctness. The code should do what you expect/want it to do. This is followed closely by maintainability. The code should be easy to read and modify. These are the two most important aspects and I believe all other rules or methodologies out there are in service of these two things. Normally the maintainability side of things as correctness is not that hard to achieve with any system of rules out there.
You must resist the urge to make your little corner of the code base nicer than the rest of it.
Uhg. I really don’t like these words. I agree with their sentiment, to a degree, but they make it sound like you should not try to improve anything at all. Just leave it as it is and write your new code in the same old crappy way that it always has been. Which is terrible advice. But I get what they are trying to say - you should not jump into a area swinging a wrecking ball around trying to make the code as locally nice as possible at the expense of the rest of the code base and other developmental practices around.
In reality there is a middle ground. You should strive to make your corner of the code base as nice as possible but you should also take into account the rest of the code base and current practices as well. Sometimes having a little bit better local maintainability is not worth the cost of making the code base as a whole less maintainable. Sometimes a big improvement to local maintainability is worth a minor inconvenience to the code base as a whole - especially for fast moving parts of the code base. You don’t want something that no one has touched in 10 years to drastically slow down current features you are working on just to keep things consistent.
Yes consistency is important. But things are far more nuanced than that statement alone. You should strive for consistency of a code base - it does after all have a big effect on the maintainability of the code base. But there are times that it hampers maintainability as well. And in those situations always go for maintainability over consistency.
Say for instance some new library or an update to a library introduces a new much better way of working. Your code base is full of the old way though. Should you stick to the old way just to keep up with consistency? If the improvement is good enough then it might be worthwhile. Ideally if you can you would go though and update the whole code base to the new way of working. That way you improve things overall and keep consistency of the code base. But that is not always practical to do. It might be better to decide that the new way is worth switching to for new code, and worth refactoring old code when you are working in that area anyway but not worth the effort of converting the whole code base at once. This makes maintainability of the new code better, at the expense of old less used code.
But the new way might not be a big enough jump in maintainability of new code that it is worth sacrificing the maintainability of the code base as a whole. Every situation like this needs to be discussed with your team and you need to decide on what makes most sense for your project. But the answer is not always that consistency is the most important aspect. Even if it is an important aspect.
As far as improving your corner of the code goes I would say a consistent style is important but having 500 lines per function is not a style. If someone will complain about efficiency (function call stack etc) then someone needs to identify what parts are truly time-sensitive. It’s likely not the entire codebase.
Wrangling a monster code base really requires a product owner. If one person doesn’t own the application as a whole then there’s no hope of consistency in the first place.
Common criticisms here would be that these endeavors stifle creativity and show the adoption of modern solutions. That said, I find conducting “code archeology” to figure out the idiomatic way of doing something in an old project very rewarding. Because computer programs exist in people’s mind’s, doing that with the support of original developers or subject matter experts is some of the most effective knowledge transfer I’ve ever witnessed.
Consistency is NOT the most important thing. Correctness is. This guy has been in the trenches flinging shit too long. I work with vendors and do my best to use the subset of their product that actually works correctly. I don’t want new features to work like shit just because the old ones did too.
Consistency is NOT the most important thing. Correctness is.
What point do you think you’re making? I mean, do you think anyone looks at a PR and says “this PR is clearly wrong, but it’s so consistent that I must approve it.” That’s obviously not the point, is it?
I’ve definitely seen “this is more correct, but all the other code does it like this so can you change it?”
I can’t say I entirely disagree with it either - usually the “more correct” is not “the existing code doesn’t work at all”, and keeping it consistent makes it easier to fix all of the code later, because you’re only fixing one style instead of two (or more).
I found the title of that section slightly triggering too, but the argument they lay down actually makes sense. Consistency helps you to achieve correctness in large codebases, because it means you don’t have to reinvent what is correct over and over in separate pockets of the codebase. Such pockets also make incremental improvements to the codebase harder and harder, so they do come back to bite you.
Your example of vendors doesn’t relate to that, because you don’t control your vendor’s code. But you do control your organisation’s.
Consistency as a means to correctness still means correctness is the more important aspect. Far too many projects and people that go hard on some methodologies and practices lose sight of their main goal and start focusing on the methods instead. Even to the point were the methods are no longer working toward the goal they originally set out to accomplish.
Always have the goal in mind, once your practices start to interfere with that goal then it is time to rethink them.
I’m not arguing against that. Merely providing some counterweight to the idea that the author was “flinging shit in the trenches” 😅
From a maintainability point of view consistency is important. I’d rather work with an consistent but incorrect code, than correct bit inconsistent code. With a consistent code base it’s easier to do something about the incorrectness, especially if it’s consistently incorrect. It’s also easier to delegate the work.
Code is rarely correct forever. Sooner or later, requirements will change. What once was thought to be correct is no longer correct. It’s difficult to do anything about it if the code is inconsistent as well. It requires a lot of mental effort to understand the thought process behind some code.
I agree that correctness is the goal, but consistency is one of the best ways to ensure this goal.
- Single-digit million lines of code (~5M, let’s say)
- Somewhere between 100 and 1000 engineers working on the same codebase
- The first working version of the codebase is at least ten years old
Things like this is where the company can save money by scraping it and start from scratch, this time doing it right.
And in rust!
Or at the very least, so long as its http driven, put a proxy in front and on the backend break up common features into microservices. With a proxy the consumers will have pretty much no idea they went from talking to one service to a dozen.