The author doesn't take the next logical step: what factors prevent the reorganization of a program?
One factor that comes to mind: lack of automated tests. Those working on the program are scared to change anything for fear of breaking something.
The author doesn't take the next logical step: what factors prevent the reorganization of a program?
One factor that comes to mind: lack of automated tests. Those working on the program are scared to change anything for fear of breaking something.
These tests have to be at the right level. Unit tests are the easiest to write, but unit tests can be pretty brittle. Reorganizing the codebase can result in many unit tests breaking (or being made redundant), which might lead to stagnation from fear of breaking tests (and the extra work of fixing them). System tests are much harder to write, but are invaluable during a major refactoring. You want to be sure that you're not changing the behaviour of the system while changing its structure.
The V-model is (IMO) an underappreciated tool in the development lifecycle.
Now the next cycle will have to understand not only the code, but why some test is validating some unused endpoint with data you never thought possible
My colleagues think I’m an idiot writing too many comments and being too careful.
We can’t ship any feature in less than 3–4 weeks, most of the codebase is an inscrutable mess, and we introduce regressions all the time (unit tests are for losers)