ManagementSpeak: We just upgraded to a new version of the software.
Translation: Not only does the software not work the way you expect it to, it doesn’t work at all.
Okay, I admit it — no manager said this. I just “upgraded” to some new software that doesn’t work at all.
Year: 2008
A progressive view of IT
More than in any presidential election in recent memory, 2008’s candidates will be notable for uttering far less nonsense than the commentariat.
To illustrate: The reliably pseudo-eruditic George Will said, in a recent column: “Most improvements make matters worse because most new ideas are regrettable …”
So there we are. A few millennia after the Jews and Greeks invented the idea of progress, Mr. Will is ready and willing to bury it for us: This from a guy who doesn’t accept e-mail but has for inexplicable reasons endorsed the designated hitter.
George Will isn’t the only one with no confidence in progress. For example, I’ve worked with quite a few companies that avoid application upgrades in much the way campers avoid rabid badgers, although with less justification.
The attitude is understandable. Upgrades range from aggravating to horrible.
They don’t, of course, have to be as painful as some companies make them, especially the ones that consciously decide to go it alone with an application, usually because of the “need” to customize core code.
The result is predictable: Great pride in the result, right up until the time when the great pride is replaced by regret at having painted themselves into a corner. They discover their corneredness either because they’ve had to install a new version of an operating system or DBMS and their ancient application release won’t run on it; or someone outside of IT looks at the new version and says, “Wow! This has some features we could really use!”
This is why smart companies, when working with a package: (1) “Customize” it through use of its built-in configuration tools; (2) customize it by building stand-alone modules that integrate through its documented APIs or other entry points; or (3) adapt business processes to fit within the package’s constraints.
That’s applications. Companies avoid software platform upgrades at least as often, which in practical terms means they freeze versions of either an operating system or a database management system.
When a company upgrades an OS or DBMS, it’s a pretty good bet many of the applications that run on the platform will have to be tweaked to continue to run. It’s a process that requires a lot of time and effort, in an era in which many of the new features we see from software vendors appear to be justified principally by someone having thought of them without anyone else coming up with a better idea. Vista and Office 2007 are the poster children for this syndrome … if either has serious business-value-creating new features beyond what XP and Office 2003 had to offer I’ve yet to find them … but they are merely more visible than plenty of other equally valid examples.
So the decision is understandable, if misguided. Pay it now or pay it later. The more versions skipped, the more painful the upgrade when it finally happens.
Meanwhile, Mozilla has just changed the situation, and for the better, George Will notwithstanding.
Which leads to a prediction: Firefox 3 will turn out to be disproportionately influential in setting the direction of future software development, and not because of any new features.
While I’m sure it has them, many nifty, which I might even discover sometime, its niftiest new feature is that it renders pages a whole lot faster than Firefox 2.
Imagine every software vendor following suit. Right now, most of them too speedily push new features out the door. In the future, what would be speedy is their software compared to the previous version.
For decades, software engineers have complained that features, no matter how sloppily implemented, are all that matter. Nobody has cared about code quality.
Their arguments fell on deaf ears because their arguments made little business sense. New features used to reliably deliver additional business value. Code quality did not in any clear and marketable way.
The situation has changed. Quantum leaps in hardware performance aren’t as reliably certain as they used to be and data centers are running low on power. One result: Software vendors can’t count on increasingly fast hardware to overcome increasingly slow software.
Just as replacing a gas guzzler with a hybrid compensates for high fuel prices, so upgrading to software whose principle selling point is efficient processing will replace hardware upgrades as the most expedient way to improve performance.
That’s real progress. That it’s not in the same direction as it used to be is no reason to lose confidence in the concept.