Constantly changing frameworks/APIs - how do we keep up?

Question

This question isn't really for any specific technology but more of general developer question.

We all know from experience that things change. Frameworks evolve, new features are added and stuff gets removed.

For example, how might a product using version 1.0 of the "ABC" framework adapt when version 2.0 comes along (ABC could be .NET, Java, Cocoa, or whatever you want)?

One solution might be to make the frameworks backward compatible; so that code written for 1.0 will still work in version 2.0 of the framework.

Another might be to selectively target only version 1.0 of the framework, but this might leave many fancy new features unused (many .NET 2.0 apps seem to do this)

Any thoughts on what we as developers should do as best practice to keep our technologies up to date, whilst not breaking our applications?

Answer 1

Oh, the possible answers....

My thoughts, while not unique (to be sure) go pretty much like this.

1. Branch your code in your source control -- you're using source control, right?
2. On the branch, update the framework (or what have you)
3. Fix the problems in your unit tests. Take advantage of the new Framework APIs, remove depreciated references, etc
4. Thoroughly test.
5. [optional] push back in to trunk (this and 4 could probably be flipped)
6. Release to production - congrats, you are now on the new framework.

It's not really that easy but I do believe the simplest answer is likely the best answer. You must just move forward...

Answer 2

Anticipate and invest in change.

Many businesses seem to think change is a bad thing. It complicates an otherwise working process. But as developers, we tend to see things differently.

Change, specifically new versions, can bring on many good things, like security updates, performance enhancements, and features. And more often than not, change is inevitable. So why not look at it as a reality of situation instead of a surprise?

You can do things like keep your data backed up in a non-vendor-specific format in case some new fangled technology doesn't work out and you need to jump ship.

Also, if you have the resources, you can keep old and new versions of something running concurrently. Ideally, you wouldn't want your production systems to be running the latest and greatest software until someone has evaluated it and signed off on it. Things like unit tests and beta/development clones of production systems can aid in this process.

Change should be embraced, not feared. Developers, stakeholders, and business people alike should be keeping abreast of new technologies and frameworks. Always be poised to address change. In Soviet Russia, API keep up with you!

Answer 3

The only two "solutions" I see are what you suggest: to keep or to upgrade to the new framework. I think that generally, when your API receives a major update and your software is important, it's probably best to evaluate the benefits of upgrading and if those benefits outweigh the time necessary to upgrade then the best course of action is to upgrade.

Answer 4

Pick a conservative, risky, or in-between approach appropriate to your business and follow through.

For example, if your company is about innovation you'll need to be able to use the latest versions of frameworks-- or at least freely investigate them. You'll need to hire people who are interested and comfortable in such an environment-- some developers are really excited about this, others not so much. Put in some structure to make upgrades safe (branches and static architecture). The customers should understand the benefits they are getting by being with such a cutting edge company-- if you're not communicating this to them, it may not be something they value, and they'll be (rightfully) upset when things break because of a system update.

Or pick a conservative approach. Pick a solid, well-worn technology and don't plan on updating it, except for minor releases. In your words, target a specific version. Hire people that appreciate this type of environment.

Or pick something more in the middle of the road.

Each of these approaches are appropriate at different times-- I've been on both extremes on different projects.