Comment by bottlepalm
13 hours ago
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.
13 hours ago
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.
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.
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.
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.
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.
1 reply →