New Orleans 2.0 - version management from a different perspective
Had an interesting discussion with some colleagues recently about version management. Versioning is often a long conversation and has many theories / best practices. In order to gain a different perspective, we talked about it using New Orleans as the object to be versioned (not sure exactly how this got started). Using this analogy strips away the technical associations and assumptions that traditionally come up in these conversations.
At any rate, we began with New Orleans 1.0, founded in 1718 according to wikipedia (so it must be true). One can say that ownership is a reason for versioning, so the ceding of the city to Spanish control in 1763 could be considered a "New Orleans 1.1". The city had not physically changed and everything was still as it was. That is to say it was "backwardly compatible". Then another version came in 1801 when it reverted back to France and finally again in 1803 to the U.S. via the Louisiana Purchase. This puts us as New Orleans 1.3. A few thought ownership itself could be a major not a minor version, a "2.0" so to speak, but most though not.
One can also say that events since then were all backwardly compatible. The city never moved or completely burned. Its inhabitants grew but did not fundamentally change. Major improvements would be a good reason for a revision, such as the massive levee system created by the Corp of Engineers. This is the equivalent of adding new functionality while maintaining backward compatibility. Each new revision enabled the city to grow, better deal with problems, or overcome obstacles. Discovering oil is an example of a growth change. Creating the levees for flood control illustrates better problem management. Finally, the installation of railroads overcame problems with transportation of goods. In short, the revisions were "enablers". So the 1.x version of New Orleans created a usable, creative, and culturally robust product.
But there was a problem. The geography and elevation of the city made it vulnerable to hurricanes. A flaw existed in the 1.x. The city tried to fix this vulnerability with a backwardly compatible change, namely the levee system. And indeed this revision seemed to be working. But the fierceness of hurricane Katrina showed that the flaw in New Orleans 1.x still existed and was not adequately fixed.
So what to do? Create a 1.x+1 of the city with even bigger and more massive levees? That seems to be the solution in the works. But yet another revision seems like less of an enabler than a patch for preventing the object from failing. This is certainly analogous in software where patches and revisions are early enablers. But at some point they become band aids meant to retain the original. Plugging a leaky boat to use one colleague's poor analogy.
So we asked each other "should the city be moved to higher ground where it was less vulnerable to hurricanes?" It was agreed that this move would have to be considered non-backwardly compatible. One simply cannot pick up the French Quarter, move it, and expect it to be the same as it was. A geographic move, while fixing the problem, would be a major version. It would be New Orleans 2.0.
But is New Orleans 2.0 still New Orleans? Is the essence of the city inexorably tied to its original major version number? Will it forever have to be 1.x? At what point do you have a new object altogether? We were so used to asking these questions in the context of technology.
While we weren't entirely in agreement, there was a lot that we did see similarly. Raising the levees would be a 1.x+1 and would be a huge patch (not so much an enabler). Moving the city would be a "2.0" and not a "1.0" of a different city. New Orleans could be majorly versioned and stay New Orleans. But should it? We were divided on the policy of patching the levees. Saving the city at all costs was analogous to saying "maintain backward compatibility at all costs". Whereas moving the city could be translated into "don't let backward compatibility prevent you from innovating and creating better solutions".
And that was where it ended. We tended to agree on the definition of major and minor versions. However what "should" be done, or the policy, was not as shared.
I think I've been here before, but starting from a much different origin.
At any rate, we began with New Orleans 1.0, founded in 1718 according to wikipedia (so it must be true). One can say that ownership is a reason for versioning, so the ceding of the city to Spanish control in 1763 could be considered a "New Orleans 1.1". The city had not physically changed and everything was still as it was. That is to say it was "backwardly compatible". Then another version came in 1801 when it reverted back to France and finally again in 1803 to the U.S. via the Louisiana Purchase. This puts us as New Orleans 1.3. A few thought ownership itself could be a major not a minor version, a "2.0" so to speak, but most though not.
One can also say that events since then were all backwardly compatible. The city never moved or completely burned. Its inhabitants grew but did not fundamentally change. Major improvements would be a good reason for a revision, such as the massive levee system created by the Corp of Engineers. This is the equivalent of adding new functionality while maintaining backward compatibility. Each new revision enabled the city to grow, better deal with problems, or overcome obstacles. Discovering oil is an example of a growth change. Creating the levees for flood control illustrates better problem management. Finally, the installation of railroads overcame problems with transportation of goods. In short, the revisions were "enablers". So the 1.x version of New Orleans created a usable, creative, and culturally robust product.
But there was a problem. The geography and elevation of the city made it vulnerable to hurricanes. A flaw existed in the 1.x. The city tried to fix this vulnerability with a backwardly compatible change, namely the levee system. And indeed this revision seemed to be working. But the fierceness of hurricane Katrina showed that the flaw in New Orleans 1.x still existed and was not adequately fixed.
So what to do? Create a 1.x+1 of the city with even bigger and more massive levees? That seems to be the solution in the works. But yet another revision seems like less of an enabler than a patch for preventing the object from failing. This is certainly analogous in software where patches and revisions are early enablers. But at some point they become band aids meant to retain the original. Plugging a leaky boat to use one colleague's poor analogy.
So we asked each other "should the city be moved to higher ground where it was less vulnerable to hurricanes?" It was agreed that this move would have to be considered non-backwardly compatible. One simply cannot pick up the French Quarter, move it, and expect it to be the same as it was. A geographic move, while fixing the problem, would be a major version. It would be New Orleans 2.0.
But is New Orleans 2.0 still New Orleans? Is the essence of the city inexorably tied to its original major version number? Will it forever have to be 1.x? At what point do you have a new object altogether? We were so used to asking these questions in the context of technology.
While we weren't entirely in agreement, there was a lot that we did see similarly. Raising the levees would be a 1.x+1 and would be a huge patch (not so much an enabler). Moving the city would be a "2.0" and not a "1.0" of a different city. New Orleans could be majorly versioned and stay New Orleans. But should it? We were divided on the policy of patching the levees. Saving the city at all costs was analogous to saying "maintain backward compatibility at all costs". Whereas moving the city could be translated into "don't let backward compatibility prevent you from innovating and creating better solutions".
And that was where it ended. We tended to agree on the definition of major and minor versions. However what "should" be done, or the policy, was not as shared.
I think I've been here before, but starting from a much different origin.
posted by Paul at
4:52 PM
