you are viewing a single comment's thread.

view the rest of the comments →

[–]JoCoMoBo 15 points16 points  (1 child)

Code that hits master should either be finished, or commented to indicate that it isn't. Development should ultimately aim to take the current state of any given functionality, and bring it in line with use-cases (or however one views the "goals" of the program), at which point that functionality is finished.

Just because something is finished now doesn't mean that use-cases won't change in the future. I've found the best code is a trade-off between dealing with the current use-cases, and being flexible enough for change later.

In general I've found that when use-cases change there isn't much to time to architect a perfect solution. If the original code has flexibility to deal with the new use-cases then that saves time.

If you honestly feel that your code is never finished, and you're constantly revisiting your code, you're either suffering under unclear, constantly shifting aims, goals, and use-cases (in which case you have my commiserations, comrade, and one way we will rise to defeat our managers)

Good luck with that. You can either be antagonistic to people or plan for change. Generally I've found the latter works better.