Is It Upward Compatible?


Don't bundle UC changes with the NUC changes where you can avoid it. Your job is basically to identify a way to transform the NUC change into an UC one, with as little risk and impact as possible. OK, our network is going to be down for 2 hours. If all the NUC stuff, and only the NUC stuff is done in that 2 hours, it's easier to believe the downtime estimate. It's easier to roll back if something goes wrong. It's easier to understand the risks. Then when the network is back up, add the rest of the changes in - the same day or over the next few weeks. Unless there's an urgent concern, it won't matter much. And the customer knows the network will remain up.

Eventually you'll start to use foresight, such as enabling the previous release before it is shipped, with the proper data structures so that conversion to the next release is painless. If you work at identifying (and I would argue implementing) NUC changes near the beginning of your release development cycle, there's a good chance you'll have time to put some hooks into the previous release before it's widely distributed.

About the author

Joe Farah's picture Joe Farah

Joe Farah is the President and CEO of Neuma Technology and is a regular contributor to the CM Journal. Prior to co-founding Neuma in 1990 and directing the development of CM+, Joe was Director of Software Architecture and Technology at Mitel, and in the 1970s a Development Manager at Nortel (Bell-Northern Research) where he developed the Program Library System (PLS) still heavily in use by Nortel's largest projects. A software developer since the late 1960s, Joe holds a B.A.Sc. degree in Engineering Science from the University of Toronto. You can contact Joe at

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!