Hacker News Reader

Comment by bottlepalm | Hacker News Reader

A lot of people say you need to go through at least three versions of something before it is mature - and v3 is not something you can design upfront. You need to see v1 both in code, and at runtime. Use it, get the feedback, and iterate. This is where AI tightens that loop immensely.

Lost you in the last paragraph - features are not "copy pasting because you already have all the building blocks" and "something may be twenty lines of code". Mid sized features often mean tearing up many layers of code across the stack to add in some sort of new capability. Tearing up existing code means there are all sorts of add-on considerations in addition to feature you are working on.

View on HN

> Mid sized features often mean tearing up many layers of code across the stack to add in some sort of new capability

What? No, it shouldn't. I've worked on a lot of codebases and if you have to do this, something is very, very wrong.

Nothing wrong at all. Some features you can bolt on, and some features fundamentally change how a system works requiring changes at many different levels of the stack. Happens all the time.

It happens in poorly factored codebases. If you find it happening that's a sign you need to refactor. If you find it happening repeatedly in the same codebase that means you failed to refactor properly the first time.

Refactoring is the natural evolution of a growing application. Refactoring too soon, too fast is what we call over engineering. Too little refactoring and your code becomes spaghetti slop. Regardless - the application will change across all layers across its lifetime.

How many layers does your code have?

Even with clean architecture, you only have 4 fundamental layers. And once you have v1, you’re mostly doing tweaking and copy pasting. Any huge refactoring is the business switching its main strategy.

Take an OS like OpenBSD. It has three main layers. The syscall layer, the kernel layer, and the machine dependent code. But an OS is more spread horizontally with various subsystems (process and memory, io and other device, ipc,…)

If you’ve captured your problem’s domain and adopted a pragmatic architecture, you will rarely have to change across all layers. That’s costly and happens mostly due to business reasons.

Lets see, front end presentation, front end service, frontend api, backend to front end (BFF) api/routing, BFF logic, BFF api, backend routing, backend logic, backend database, worker routing, worker logic, worker storage.

And then the each of the service layers can be broken into layers themselves depending on the complexity of the business logic can be broken into layers as well. So yea a change in a worker can potentially bubble up through all the layers.

In a worker? ...How? I seriously want to know.

Then I’d suggest you take a step back and truly think about the design of your project. Before even coding, you should start thinking about contracts (interfaces) between those so implementation changes does not ripple across the whole project. Having a change in a worker bubble up is a sure sign of a big ball of mud[0].

[0] https://www.laputan.org/mud/mud.html#BigBallOfMud

Overengineering is totally a thing, yes. If you want to make a proof of concept or you have no customers, that's fine, ship it.

There's such a thing as under engineering, and if you find yourself changing "all the layers" for a feature, your codebase is poorly designed.

Not many industries can afford refactoring of the code is not supposed to be changed - additional (unexpected) regression testing costs, risk of downtime, etc. You learn that if it works and is in production - don't touch it.

This likely assumes you have a mature and well designed (architected) code base. That is not always the case, and as features get added and removed, that won't be the case at all until there is a refactor.

Reply on news.ycombinator.com