4 ms·

If your code ends up like that you probably missed having a sustainable rate, pair programming, code reviews, refactoring and writing testable code. So you mis

If your code ends up like that you probably missed having a sustainable rate, pair programming, code reviews, refactoring and writing testable code. So you missed a lot.

Silhouette 14y ago
Unfortunately, the reality is that any code base that is maintained and developed over an extended period will "decay", even if you don't do anything wrong. This is a simple consequence of the fact that you usually don't know everything and can't create an idealised long-term plan up-front. Instead, you start with certain goals and try to implement a sensible system that meets those goals. As time goes by, your goals change or you add new ones, and you have to adapt that existing system to match. Often, during the time since the initial development was planned out, you may have developed newer techniques for solving your problems, or you may have new tools available that weren't before, or you may have worked with some new people who have better ideas about something. In short, you may have a better way to do things than before. Now you have exactly three choices: 1. Stick to your existing design/ideas and don't use the better ways. (Pros: Maintains consistency and doesn't incur (re)training overheads. Cons: May cost more and/or get worse results for the new work, or may simply not be possible if you need a new approach to satisfy your new goals.) 2. Use the better ways, but only for new/future work. (Pro: Best cost and results for that new work taken in isolation. Cons: Might mean an entire new design co-existing with your previous one(s), with potential compatibility problems, integration costs, future maintenance overheads, etc, and might cost more to implement separately than it would have done if you'd known ahead of time and created a more general design to support both the old and new parts earlier.) 3. Switch everything to the better ways, a.k.a. The Big Rewrite. (Pros: Keeps your entire system using the best possible tools/ideas, and keeps the whole code base consistent and systematically designed across the board. Cons: Can be extremely expensive relative to incremental changes, you can easily lose little fixes/improvements that had been carefully worked into the original code base over time, and you may have to retrain some of your team before they can work with the new version.) This is an exhaustive set of your options if you're going to do that new development but your team and the world have moved on since the original work. Every one of them has at least one serious downside, and unless you do a full rewrite across your entire code base every time you develop any improvement, those downsides always include some degree of inconsistency or stagnation.

If your code ends up like that you probably missed having a sustainable rate, pair programming, code reviews, refactoring and writing testable code. So you missed a lot.

Silhouette 14y ago

Unfortunately, the reality is that any code base that is maintained and developed over an extended period will "decay", even if you don't do anything wrong. This is a simple consequence of the fact that you usually don't know everything and can't create an idealised long-term plan up-front. Instead, you start with certain goals and try to implement a sensible system that meets those goals. As time goes by, your goals change or you add new ones, and you have to adapt that existing system to match. Often, during the time since the initial development was planned out, you may have developed newer techniques for solving your problems, or you may have new tools available that weren't before, or you may have worked with some new people who have better ideas about something. In short, you may have a better way to do things than before. Now you have exactly three choices: 1. Stick to your existing design/ideas and don't use the better ways. (Pros: Maintains consistency and doesn't incur (re)training overheads. Cons: May cost more and/or get worse results for the new work, or may simply not be possible if you need a new approach to satisfy your new goals.) 2. Use the better ways, but only for new/future work. (Pro: Best cost and results for that new work taken in isolation. Cons: Might mean an entire new design co-existing with your previous one(s), with potential compatibility problems, integration costs, future maintenance overheads, etc, and might cost more to implement separately than it would have done if you'd known ahead of time and created a more general design to support both the old and new parts earlier.) 3. Switch everything to the better ways, a.k.a. The Big Rewrite. (Pros: Keeps your entire system using the best possible tools/ideas, and keeps the whole code base consistent and systematically designed across the board. Cons: Can be extremely expensive relative to incremental changes, you can easily lose little fixes/improvements that had been carefully worked into the original code base over time, and you may have to retrain some of your team before they can work with the new version.) This is an exhaustive set of your options if you're going to do that new development but your team and the world have moved on since the original work. Every one of them has at least one serious downside, and unless you do a full rewrite across your entire code base every time you develop any improvement, those downsides always include some degree of inconsistency or stagnation.