IT projects, like tattoos, are commitments. You wouldn’t accept that kind of answer from a tattoo artist, it’s your body, you have the right to change your mind as long as the ink is not under your skin. Why would that be different for software development ? Why would requirements be written into stone once they were signed ?
One could explain the too common attitude towards change by two main factors:
- process momentum
- stability issues
Process momentum is the consequence of everyone trying to protect their butt from backfires in case of project failure. As long as you can blame someone else for failure, you think you are safe, but in companies, the way to design the scapegoat is by signing contracts, SLAs, and other forms of paperwork. Every time you make a change in the requirement, someone can feel the contract terms have changed, and therefore, his paper walls are not protecting him anymore. Therefore, either you don’t make changes, either you spend a lot of valuable time to sign agreements.
Stability issues are the quicksand in which developers who don’t practice testing at a sufficient level are thrown when the requirements drift too much from the initial requests. That’s the typical “We will soon release a patch to fix the bugs introduced by previous patch. Sorry for the inconvenience.”. When you designed things like this and they end up looking like this.
The Agile manifesto states “Customer collaboration over contract negotiation”. Customer don’t change the requirements because they are evil, or helpless, but because they found a new way to improve their work. That’s what we do, helping them get their work done, and if possible, done better than their competitors. Don’t think of change as a mutation, but as an evolution.
If our quadruped, monkey-smelling ancestors decided that “walking on our rear limbs was not part of the original design”, just imagine where we would be now. Evolution is the way every live being manages to keep up with changes in its environment. Not changing (or changing two years too late), means putting your own kind in danger. If you eat beef and the new breed of beefs grows two more legs, you’d better find a way to continue chasing them, either by becoming smarter, either increasing your muscular mass (or number of legs, but that’s just gross).
If you eat money, and the competitor grows a new technology to eat more money than you (and possibly start eating your money), you’d better evolve your own tech right now !
How to evolve safely
Even if it’s hard to throw all that good paper, all those UML diagrams (I like UML, not the “armchair” developers/teachers who waste paper drawing them instead of coding) and SLAs, do yourself a favor and burn it. The world won’t fall apart, but your butt won’t be covered whatever you do anymore. Better deliver quality from now, isn’t it ? But how ? How can I keep up with the pace the user are changing my specs ? Here are a few tips to help in those difficult times:
Buy sketchbooks
Sometimes, the product works as expected, but the user spends weeks arguing on what the default font of the application should be, what color each list item should be, “do we use bold for new items ?”, “should all names be uppercase ?”, and so on. Instead of going into a crazy hack-release-hack session, take a piece of paper.
It’s so damn simple to draw a little window on paper, with the user seated at your side, and to play “let’s imagine it’s your finished application, now where do you click ?” game. Sketches are cheap, everyone can draw a box, a line, a reversed triangle and a cross, so virtually everyone can draw the whole Windows environment GUI toolkit. It just takes a minute to make a rough usability test and usually customers react well and after the first embarrassing moments when they look at you like if you were the mad hatter, they start making comments on how the UI is laid out, or notice that something went missing.
A sketch is like a dynamic screenshot of the final product. But the cost of changing something on the paper is nothing compared to the cost of changing it in the real application. So if the customer is still hesitating at some point, then pull out your pencil box before addressing anything else.
Practice smarter design
Some other times, UI is fine, but the business code keeps changing all the time. Perhaps the analysis was done too early, and people did not have yet all the project in mind. They gave everything that came to their mind at this time, but now that the project is taking of, they suddenly remember a lot of things that completely change the way the application works.
If you were familiar with TDD and loosely coupled elements before, you are lucky because those new requirements only mean some relatively small rewrites here and there. If you are not, then you should start using it from now. TDD, if you take it seriously, will force you to write flexible and maintainable code. Flexibility is not the ability to touch your toes with your forehead, it’s the ability to make major changes in an application, with little (or limited) changes to the code.
When a new requirement arrives:
- You find the tests that are linked to the feature that is impacted
- You change the inputs/expected outputs for those tests, so they match the new requirements
- You run the tests, see them fail, and go to everywhere it breaks to fix it
- When the tests do not break anymore, then you are done, right ?
Release more often
Ok, now the UI is nice, the product is stable, but the marketing department floods you with buzzword technologies you should use immediately, instead of the ones you already have implemented. You have then several ways of handling the situation:
- the slave: “Yes, of course, we’ll throw everything to please you, my lords”
- the coward: “It … was … not … in the requirements !” (damn you, you couldn’t help keeping a copy, uh ?)
- the greedy: “Well, gentlemen, we will do whatever you wish, but we will need more men to work on the project, and will update our prices in consequence”
- the professional: “Listen, we are currently working on a version supporting technology X that will be released next week. We will not change anything for this version, but we’ll read your submissions and use them for the next cycle that will last two weeks, in which we will be using technology Y.”
Actually, it can sound like I’m twisting the principle of being reactive to change, by freezing the requirements for a couple of weeks. Well, what are two weeks of frozen specs, when you know that some projects take month or years (or decades) to complete ? Two to six weeks are enough time for the developer to be confident with his tools, approach and framework. It’s not enough however to lose strategical advantage to the competitors. We are not twisting the idea, we are using it with common sense.
For further reading, I recommend:
- The twelve principles behind the Agile manifesto
- XUnit Patterns.com website, especially the “Test Smells” part
- my earlier post on transparency