On dev software upgrades–when, why, how?

A few months ago, a client had made a few changes in some nifty little WinForms application I’d written for them and then wanted me to pick it up again from there.

I know that sounds like a nightmare, but the person who did the changes is really sharp, and he definitely improved on my work. So it wasn’t like I had to go and fix all the problems he introduced. There weren’t any.

No, I’m writing this because of a different complication.

See, I’d used Microsoft Visual Studio 2005 to write the original program. The client was standardized on Visual Studio 2008, so they were easily able to load and build the C# code. But then I couldn’t load their updated version into my one-version-behind installation.

It was no big deal, actually, because I needed to buy and install that version upgrade sooner or later anyway.

Yes. I’m lazy. A good kind of lazy.

I realized though that that is my upgrade strategy: “buy and install, sooner or later.” It’s like the “lazy evaluation” algorithm in some programming languages–putting off the expensive and time-consuming tasks until you know you’re going to need them. Sometimes they don’t need to be done at all.

In Agile terms, we  put it this way: you ain’t gonna need it, or “YAGNI” for short. There’s never a benefit to having a feature implemented before someone needs to see it or use it in some way, because the seeing and the using are the only reasons you’d bother in the first place.

Now as an independent consultant, who generally pays for his own tools, for me this is a great strategy. There are products I ended up never buying, operating systems I never installed, tools I didn’t get around to trying out. In a way, I count each of those instances as a win.

You totally want to read more about this, and you will, if you get onto my eZine list. You get a complete mailing about once a month, with articles and links and special offers that help you do your job, as well a quick note every week or so with something funny or interesting. Do you need help, insight, and entertainment? Then this is for you.

Is that so wrong? It feels like I’m proud of my ignorance. I tend to miss some swirls and eddies in the tides of technology, true–such as never having had Vista on any computer I’ve owned. On the other hand, was missing out on Vista so bad?

A necessary evil?

Maybe not. I’m saying that upgrades are not always evil, but they’re not always necessary either, so that point of view is necessarily kind of speculative.

When I ran this question past my LinkedIn network (thanks everyone!) I got some really interesting and surprising responses:

  • “We often wait until versions go definitively out of support before making changes.”
  • “The reason to upgrade regularly is that employers are asking you to have experience with the latest tools and software.”
  • “Each upgrade to our toolchain poses a risk, so we only upgrade to fix major showstopper bugs…. We are still on VC6 for the primary project I work on.”
  • “When I do finally upgrade my dev environment… I always take a complete snapshot of the VM.”

In summary, what I heard from my network came down to:

  • In the production toolchain, upgrade only when you simply have to.
  • Alternatively, upgrade the production toolchain when there is a specific quality benefit to doing so.
  • In big shops, an upgrade is a project unto itself. Treat it like one.
  • In sandbox and R&D environments, use virtual machines to try out new versions of everything, check compatibility, and learn.
  • Experimenting with the new releases, at least, is probably good for your career.

Excellent advice! How do you manage dev software upgrades? Hit the comments and let me know.

 

About these ads

3 responses

  1. […] This post was mentioned on Twitter by Mark W. Schumann, Mark W. Schumann. Mark W. Schumann said: How often do you upgrade dev software? I'm #agile about that, how about you? New blog post: http://bit.ly/2VTQbQ […]

  2. In my recent past at a larger IT organization, upgrades were indeed projects unto themselves. Prior to my leaving, as soon as you completed one you immediately started a new one because the start to finish was about 1.5 years and growing. That may give you some sense of size and scale of the technology. The next trick is determining how to get those dull and boring to the business project prioritized high enough to make traction. Luckily, the system I referred two was a customer facing SSO solution that needed to grow and scale ahead of the user base. If it failed, all the products behind it failed. So, upgrading to keep pace with new version performance enhancements was critical. You could only tune the current version to a point and then the new version re-architected some component allow my throughput and thus upgrading was needed otherwise there really were no alternatives.

    Some thoughts I’ve collected similar on my blog: http://bit.ly/Ya8TQ

  3. Scale makes a huge difference in how you approach these things. Upgrading a dev tool when you’re a solo developer handling a few active projects with maybe a dozen or so in slow-maintenance mode is one thing. Tracking an enterprise-wide single signon? Wow. Totally not the same. It must be hard to get the corporate-level buy-in that you allude to, even though from the sound of it the upgrades are absolutely essential, not a nice-to-have thing.

    I am loving your “root cause” series, and the name “MidWest IT Survival” has just the right noir connotations.

    Thanks for your comment, John, and for your contribution to the local tech blog scene.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 1,512 other followers

%d bloggers like this: