Summary
It's been ages since I’ve visited a team that didn’t use some form of third-party software, something more than their platform. Often this software is integral to their work. Why don’t they treat that way?

A few weeks ago I visited a team that wanted to use version X of a tool T.

Version X of T needed version Y of an open source programming language that we'll call P.

Unfortunately, the project was already using version of Y - 2 of P and the upgrade looked hard.

They tried to find an earlier version of T that worked with V - 2 of P, and they couldn't find one. Phew! They were lucky: Now they have to upgrade!

Well, let me elaborate on that: I think they were lucky. Many of the developers think so too, but the rest of the organization? They just see the cost of the upgrade.

The thing they don't realize is that upgrading two version numbers is often easier than three.. or four.. or five... ...and, well, this was open source, but imagine getting to the point where you have to buy intermediate versions of third-party tools on eBay(!)

Dependencies on stale third-party software are sort of like areas of code that need refactoring, they are both forms of technical debt.. debt that grows over time. When we build on poorly factored code, the cost of change goes up. When we fall behind in the upgrade cycle, the cost of an upgrade goes up too.

Good teams manage their upgrade cycle. They may occasionally be behind a version or two, but they assess the cost. They keep tabs on it and most of the time, they upgrade just because, well, it's time to upgrade.

Does anyone have any horror stories?

Talk Back!

Have an opinion? Readers have already posted 7 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Michael Feathers adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Michael has been active in the XP community for the past five years, balancing his time between working with, training, and coaching various teams around the world. Prior to joining Object Mentor, Michael designed a proprietary programming language and wrote a compiler for it, he also designed a large multi-platform class library and a framework for instrumentation control. When he isn't engaged with a team, he spends most of this time investigating ways of altering design over time in codebases.