Hacker News Reader

Comment by BlargMcLarg | Hacker News Reader

Not everything needs a hyper-abstracted solution. Most people suck at writing neat abstractions, so they spend an excessive amount of time writing shoddy solutions which no one really wants to deal with but there's a soft, begrudging agreement to use them anyway while the business sees no value in having their devs rewrite it. This goes double when you step into the world of microservices, where you now have another layer where you can easily swap the implementation behind the interface.

Surely years of old Java shops with absolutely dreadful software architecture, sloppily copied from literature, showcase the path to hell being paved by good intentions.

View on HN

But factory is not "hyper-abstracted". For that matter, factory factory can be annoying, but still does not require all that much abstract thinking to understand.

It would be different if people complained about actually complicated stuff ... but, you know, factories are not difficult to understand. Even when I disagree with design decision to create a factory, it is clear what factories do.

Sure, you can write bad code using abstractions. Doesn't mean abstractions are bad or useless. There's just a lot of devs out there who don't write very good code.

There are also devs writing decent code but too tightly coupled, making it much more difficult to develop the code further without first refactoring the existing solution. It is also often very difficult to refactor the solution because its parts are also very tightly coupled so you end up with a whole tree of changes you have to make before you can do the actual refactor you want in order to make the actual change you wanted to do in the first place.

Eh. It’s usually not that hard to take two tightly coupled components and insert an abstraction layer in between. Usually tightly coupled code is small, and you can almost always use the compiler to find all the places you need to modify things.

Practically speaking I’d much rather that problem than it’s inverse. It’s exhausting dealing with code that’s too abstract. Especially if the abstractions don’t do anything anyway. Eg - Java interfaces with exactly one implementation. Removing useless abstractions never feels pressing enough to do, but you pay a tax for those abstractions constantly. And it doesn’t take many abstractions before your productivity plummets. No thanks.

The best code is like the best writing. Say what you mean. Be direct. And be humble enough to redo it all when you figure out a better way to proceed.

Two? Sure. How about when the whole application is tightly coupled so a change in one class necessitates changes in 4 others? And sure if the logic is straight forward and simple that's fine, but add in that the code is a complete mess with a bunch of weird convoluted solutions to things and whoever wrote it is long gone so nobody knows what it's supposed to do beyond "exactly what it currently does".

I think I'm pretty good at programming but that's generally what I've been doing in my career and to me it's incredibly difficult. Not that much new code, just a lot of wrangling shitty old code and in retrospect regretting that I didn't just delete it and write everything from scratch.

Bad code is still bad code. And correctly abstracting everything is still the ideal. Abstractions are like hinges. Too few and everything is a big fused mess. Too many and your system is a wobbly mess you can get lost in. You need the right abstractions in the right places.

For my money the way to do that is to start with as few abstractions as possible and only add them in the places you need them, when you need them. Start simple and refactor as you go. If you try to predict where the abstractions go before you’ve designed your system, you’ll get it wrong and then you’ll either leave your code with bad abstractions or spend far longer than you had to refactoring. (Since refactoring is harder the more code you have).

Reply on news.ycombinator.com