4 ms·

> Upgrade everything, all the time In my experience, rationality is better. Everything we do to our code assets has an associated cost. Therefore, everything w

> Upgrade everything, all the time In my experience, rationality is better. Everything we do to our code assets has an associated cost. Therefore, everything we do should have a clear justification -- unless of course you have countless world and time to spend. It would be pointless to upgrade from your old MVC framework if there's no clear and prioritized problem it would solve. Professional developers acquire tools and instincts over time--not blind rules like these--and always use their brain when solving problems.

jacques_chester 11y ago
It's worth noting that this blog post is on the GoCD website; so my expectation is that it's part of a larger theme of making testing upgrades an automated process. One thing that makes this hard is that there are so many sources of upstream variability these days. On my current project I am up to ten (or 13, depending how you count) sources of upstream changes that I can think of. And this is only a medium-sized project. My predecessors had 4-5 pairs to work with, so having a chore track humming was a viable tactic, so these could pretty much be handled manually. With 2 pairs and a lot of feature work it's much harder to justify running a chore track every day.
njharman 11y ago
> Everything we do to our code assets has an associated cost. Indeed. Not upgrading (incrementally in small, manageable chunks) is one of the highest costs to incur. Almost everything in software dev is done is small, iterative chunks for a good reason.
- wellpast 11y ago
  > Not upgrading (incrementally in small, manageable chunks) is one of the highest costs to incur. Absolutely not true as generalizable statement. Not even close. I've worked on several large software projects, from systems dev and full stack distributed web systems that have ran solidly for years and years on non-latest versions. Our productivity would have severely been hampered by a slavish adherence to a rule like this.

jacques_chester 11y ago

It's worth noting that this blog post is on the GoCD website; so my expectation is that it's part of a larger theme of making testing upgrades an automated process. One thing that makes this hard is that there are so many sources of upstream variability these days. On my current project I am up to ten (or 13, depending how you count) sources of upstream changes that I can think of. And this is only a medium-sized project. My predecessors had 4-5 pairs to work with, so having a chore track humming was a viable tactic, so these could pretty much be handled manually. With 2 pairs and a lot of feature work it's much harder to justify running a chore track every day.

njharman 11y ago

> Everything we do to our code assets has an associated cost. Indeed. Not upgrading (incrementally in small, manageable chunks) is one of the highest costs to incur. Almost everything in software dev is done is small, iterative chunks for a good reason.

wellpast 11y ago
> Not upgrading (incrementally in small, manageable chunks) is one of the highest costs to incur. Absolutely not true as generalizable statement. Not even close. I've worked on several large software projects, from systems dev and full stack distributed web systems that have ran solidly for years and years on non-latest versions. Our productivity would have severely been hampered by a slavish adherence to a rule like this.