Make it work before you make it standard
Matt Heusser has just published a post about standards. In it, he says
So, when people rush to standards, I hold back a bit. Having a standard means saying “We believe the value of doing things the same, every time, is more valuable than the value of the lessons we will learn by experimenting with new things.”
I, too, have been puzzled by the rush to standardize.I’ve often come across situations where I’ve suggested trying some tool or technique, and the response is something like one of these:
But that’s not the corporate standard.
A committee is investigating all the options and will choose the best practice/tool.
It makes you appreciate Grace Hopper’s advice, “It’s easier to get forgiveness than permission.”
Why do people want to choose a standard before they’ve tried something to see how well it works?
At one company, the small development team I was on was spread across a couple of cities. We wanted a wiki to share information amongst the team members. Of course, the corporate standard was that no servers could be run on workstations (ignoring the fact that we were running J2EE application servers, by necessity, to develop a J2EE application), so we would need permission to instruct the server team to install it. That meant that the Architecture Team had to study the available wiki software to determine which would be suitable for every use in an organization of thousands of workers–before a team of six could use one. A year later, there was still no wiki.
At another company, a new IT manager was hired to lead a team that would define the standard development methodology. After a couple of months’ study, they presented an overview of four methodologies: waterfall, RUP, spiral, and XP. None of the presentations truly represented the intent of the methodologies, and the XP one was completely unrecognizable.
The presentation kicked off a protracted wrangling among the IT managers over the direction of the standard. When the new manager left, several months later, no standard had yet been chosen.
One group, at least, couldn’t wait for the corporate standard and chose RUP. Never mind that they had no one with any RUP experience, and weren’t bringing anyone in to teach it, things were going to be better. They bought a lot of expensive software from Rational and formed their own committee to customize RUP for the project’s needs. More is better, right? The committee selected 105 essential artifacts (other than code) out of a list of 112 suggestions in the RUP manual. And eleven months after purchasing the software, they installed it on the team members’ computers. (The support contract covered the first year after purchase.)
By the time an elaborate requirements elaboration phase had been completed, time was running out for getting the software done. As can be predicted, in spite of protests and complaints by the committee that had selected the essential artifacts, the development team continued with their old code-and-fix style, giving new names to some behaviors to conform to the new expectations.
Processes, like software, don’t work well unless they, well, work. So get it working first, and then worry about whether you should standardize on it.