> If you develop a program for a long period of time by only adding features but never reorganizing it to reflect your understanding of those features, then eventually that program simply does not contain any understanding and all efforts to work on it take longer and longer.
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.
> One factor that comes to mind: lack of automated tests
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.
Writing tests without fixing the lack of understanding first is even worse.
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
That’s where comments come in. I tend to do a brain dump around the code I wrote in comments: why does this code exists and in particular why is it doing it in this horrible, convoluted, suboptimal way. I also wrote small functions and pick my variable names carefully.
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)
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.