Hacker News Reader

Comment by BurningFrog | Hacker News Reader

Only write code that's absolutely needed for what you're building.

It's very tempting to make it "extensible" by overgeneralizing. What you get then is overly complex code, most of which is never used.

Cut out everything that isn't currently used, and you have a small system where every line pays for its keep.

View on HN

This. The problem with unused extensibility is that it tends to get into the way of the extension that you will actually need... It's easy to extends something simple in any way. It's hard to refactor something that's complex.

This this. Very aptly put

100% this. Usually reviewing code of juniors one of the things that appear the most is how they try to apply patterns they read online to over abstract things that do not need to be abstracted instead of solving the business issue with the minimal code necessary.

Agreed - and note that this principle is in tension with the junior/intermediate (heck, even senior) urge to make things "easy to change" by just making everything abstract and configurable. ("See, now if we want to do it this other way in the future, we only have to flip this bit!")

I still haven't found a pithy way to describe the limitations of this principle. Obviously, frameworks are helpful and also fail this principle, so even this principle has exceptions. But are you going to be so arrogant to believe your abstract extensible change will be adopted by all your fellow teammates in the future?

I think the core problem is that it assumes you know what part of the software will need to be changed. But you often don't so you end up with code that is too rigid in places that you need to be flexible and too flexible (i.e. complex) in places that don't need it.

How I think about this is that adding this flexibility is no harder to do when we actually need it.

So there is no reason to add it now, even if we're 100% sure we'll need it. And in reality, those expectations are rarely more than ~40% true.

This goes hand in hand with refactoring as a core skill. If you're good at refactoring, you can always tweak code to do what you want.

This mostly matches what I've come to believe over the course of my career with one slight tweak: also make sure that your code can handle the immediate next thing you know needs to be done. Don't try to plan any farther ahead than that because requirements change so often that you'll just waste time, but also don't write something so hacky that you'll have to do a bunch of rework to support the feature you know have to implement next week or month.

In other words, eXtreme Programming.

Reply on news.ycombinator.com