Summary
It's been ages since Ive visited a team that didnt use some form of third-party software, something more than their platform. Often this software is integral to their work. Why dont they treat that way?
Advertisement
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.
I think you'll find this very interesting: dependencies of Visual C++ 6.0 have never been removed because managers and also many developers think of this language and platform (C++ and COM) as legacy. So, they consider products based on the platform legacy and don't upgrade. But this is still a profitable legacy, so, just continue to develop on top of it and extracting that extra margin... So, here we are in 2006 and we still have plenty of cash cows based on it. No upgrade plan, because we have digged for ourselfs a deeper and deeper hole.
When will the upgrade occur? What will be the cost? Remember all this code has no automated tests, so, its not only the cost of migration, but also testing all of this.
The upgrade will never occur. A redesigned product will be built on the current "future proof" platform and then the cycle starts again. Normally you'll have very few of the experienced and domain knowledgeable developers present, so, lots of learning and bumping into walls will be needed.
For your entertainment we are seeing it happening again with migration from JBoss 3.x to JBoss 4.x. We just don't learn.
Now you're talking about 3rd party libraries. Who cares about this when we have the inertia for the whole platform? Business is agile yes, for making re-structuring every freaking 18 months or less!
I agree with you... in a way. When upgrade is relatively easy (that is, when technology being upgraded is well-developed and backward-compatible) there is no excuse not to upgrade (and I should know, I can't get platform J upgraded from version 1.3.1 for no good reason). However, some upgrades need to be very well justified with something other then "hey, they released a new version, it must be good!". Seems like upgrade of language P in your example was not fully compatible (hence upgrade looked hard) so why would you want to upgrade without a real need? In my experience (admitedly, I am not a guru but I still have some experience :) ), upgrades of low-level technologies (runtime platforms, include languages, core libraries that are used everywhere like string manipulation or date) are worth the effort only when they can be justified, when people know why upgrade. Just my 2c.
I read the first lines of the post, and thought it was going to say this, which would have been interesting too:
A few weeks ago I visited a team using open-source technology T. T is a huge part of their business, but they never consider extending it or fixing bugs in T that were hampering their own development process.
Unfortunately they resorted to building their own work-arounds for the bugs instead.
Object-Orientation, interface-based design and particularly, components, will mitigate many problems associated with upgrades. However at minimum, upgrades will aways increase the amount of testing required.
I like how this discussion has expanded beyond third-party libraries to include things like development technologies, and OSes.
In terms of development technologies, there are ways to get components to interoperate. This is a compelling choice to consider when upgrading. Interoperation can also occur between platforms using Web Services or some other TCP/IP based approach.
Interoperating technologies digs another hole however. A hole called maintainability. It may be a challenge to find a staff that can work on a system the is comprised of interoperating COM, .NET components that interoperates with Java on a Linux box using Web Services.
Although interoperating opens up a new can of worms, it is a good migration path and is often overlooked. The main point is that code doesn't always have to be ported or redone.
Well designed C++ can also be rehosted on different platforms and can be easily componentized. I have taken good C++ code and reworked the top layer in ATL/COM and reused most of the underlying functionality. At some point I may redo the top layer as C++/CLI for .NET or I just may interoperate what I have. If I want to upgrade to Linux, We would just go back to the original C++ code and start from there.
Let me try to get firmly back on topic. I guess it boils down to the dull but important elements of our business, configuration management, scheduling and cost vs benefit analysis.
Ultimately, in the face of the complexity, doing nothing seems to be the typical approach.
It seems to me that the development team hadn't really done anything wrong. They hadn't upgraded stuff that didn't need to be upgraded until it needed to be upgraded. Certainly a multi-version upgrade <i>may</i> be more painful and a single-version one but it <i>may</i> equally be less painful than several single steps.
You complain that the rest of the organisation just sees the costs. Well, that's how it should be in any commercial organisation. All departments have a duty to minimise their costs (along with many other duties, all of which have to be balanced).
There are a number of arguments for and against continuous upgrade, all of which need to be considered on their individual merits in the particular circumstances.
That being said, it's worth noting that if the process is 'painful' then the root cause of the pain is the degree of backwards compatability in the software (or hardware) being upgraded. At one end of the scale, fully backwards compatable software should be painless to upgrade to. At the other extreme, software that has a very low level of backwards compatability is, in effect, not an upgrade at all but a de facto migration from one product to a different one (that just happens to have the same name).
In my experience, there is often little pain, or for that matter, gain in the easy upgrades and they often happen without fuss. The problems are with the pain of upgrading to new versions whose incompatabilities introduce problems; enough problems that 'the managers' notice and have to intervene. Here, it makes little difference if one or many versions were jumped beforehand. In these cases it is quite reasonable for 'the management' to ask us to justify the upgrade and, equally, quite reasonable for 'them' to turn down the request if we can't make the justification.
> You complain that the rest of the organisation just sees > the costs. Well, that's how it should be in any > commercial organisation. All departments have a duty to > minimise their costs (along with many other duties, all of > which have to be balanced).
The problem here is that in most cases the minimization is short term. With each upgrade missed bugs in the base code, now fixed in later versions, have to be worked round making the product more and more dependent on that specific version. More and more of your code has little to do with what the product is supposed to do but more to do with working round bugs - this is never a good thing.
Then a client says that it must work with the absolutely latest version of Oracle, which means that you have to upgrade not one package but practically everything (dependencies work like that). Things break. A simple task like supporting the latest version of Oracle turns into a nightmare and it will take months to shake out the bugs and strain your relationship with the client.
Just remember that couple of weeks you saved three years ago? They're back with the sort of interest that you normally associate with loan sharks.
> There are a number of arguments for and against continuous > upgrade, all of which need to be considered on their > individual merits in the particular circumstances.
Pure PHB speak, all debts will be paid. The problem is that the people who have to pay the debt are not the PHBs who saved the company a couple of weeks a few years ago.
Peter, What you said makes sense and I think nobody here says that you should not upgrade (such statement would be pretty stupid indeed, IMO). However, any upgrade should some kind of have justification (new features, fixed bugs, better support, dependencies, etc.). If you have to work around bugs that were fixed in later version, by all means you should at least consider upgrade, but if you will upgrade every library with latest versions I highly doubt it will increase your system's stability (upgrades usually introduce as many bugs as they fix, slightly incompatible features can take a while to catch and fix, etc.). Bottom line is I don't think there can be a "golden rule", like "always update" or "don't upgrade for at lest 4 years past end-of-life date". As with many other things it is about cost benefit analysis. And as with many incompetence in making decision can hurt you.
Previous Topic
