← Back to context

Comment by habinero

13 hours ago

> 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.

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.

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.

      3 replies →