Beware the Freebie
The milestones in the life of a story:
- Creation: customer creates the story
- Estimation: the story is estimated by developers
- Selection: the story is selected for an iteration
- Specification: tests are written the story
- Implementation: the story is implemented to make the tests pass
- Acceptance: the customer acknowledges completion of the story after seeing the passing tests and witnessing the new functionality
It is unavoidable. Every story must go through these milestones of life in order. A story cannot be estimated if it has not been created. A story cannot be selected for an iteration if it has not first been estimated. You can attempt to specify a story before it has been selected but you run the risk of being wrong, for the system may change many times before the story is selected. Implementing a story before it has been specified will lead to false implementations. And accepting a story that hasn’t been implemented is just plain silly.
It happens with some frequency, however, that a story gets implemented before it is ever selected, estimated, or perhaps even created. How? A developer may be look at a piece of code and think, “Hey, the customer mentioned he wanted to change this doohickey. I might as well change it now.”. Or a developer may working on one feature and say, “You know, I bet the customer would really like it if I improved this thing-a-magigger”. When this happens, the developer pridefully demonstrates the extra functionality to the customer and says with a smile, “You got a Freebie this iteration!”.
BEWARE THE FREEBIE! A Freebie, by it’s nature, has skipped at least one milestone in it’s life. Most Freebies skip the Selection milestone. This is unfortunate because maybe the customer didn’t really want that story after all. But that’s small potatoes compared to the real danger… Almost all Freebies have skipped the Specification milestone.
Skipping the specification milestone is blasphemous. If a feature has not been specified with tests, how do you know it really works? Worse, how will you know if it still works 2 months from now. Very often Freebies break and nobody knows about it.
I’ve seen it over and over and it’s regrettable every time. A perfectly innocent story is wronged by an overzealous developer. The poor story, out of sync from his peers, strays from the trodden path and becomes a Ghost Story. Becoming a Ghost Story is dreadful fate. They are those stories that were at one time complete, but have since become incomplete. You may never actually see a ghost story but they will surely haunt you. They cause users to have delusions of non-existant functionality and to make exclamations like “Hey! Why doesn’t this stupid app work like it used to?” or “What happened to my favorite feature?”. They keep customers up at night wondering if they actually selected the Ghost Story for an iteration of not. They torment developers forcing them to write code they’ve already written.
Avoid Ghost Stories by avoiding Freebies. Give every story a complete life with all it’s milestones. The next time a developers shows you extra functionality and calls it a Freebie, say “That’s nice. I’ll consider selecting a story for that in a future iteration.”
Mon, 24 Apr 2006 23:17:57, Old Grouch, Another hidded danger By skipping several stages, the freebie runs the risk of breaking something else. An assumption that doesn’t carry throughout the entire system. Usually minor, so it doesn’t show up for months. Then someone else has to rip their hair out. And declare that your parents were never married.
“The more innocuous the change, the greater the ramification.”
Tue, 21 Feb 2006 14:11:34, Gary Dieckman, Looking for Preston and Karen Martin Micah Martin - If your parents are Preston (Tom) and Karen Martin of Proctorville, Ohio, then your dad was best man at my wedding in 1970. I’d like to get in touch. Are you that Micah? gary@exprint.com
Nope, you’ve got the wrong Micah
Tue, 21 Feb 2006 14:11:34, Gary Dieckman, Looking for Preston and Karen Martin Micah Martin - If your parents are Preston (Tom) and Karen Martin of Proctorville, Ohio, then your dad was best man at my wedding in 1970. I’d like to get in touch. Are you that Micah? gary@exprint.com
Thu, 16 Feb 2006 10:09:50, unclebob, Other out of order disfunctions. Indeed! I think you have hit on an interesting way to describe a whole family of dysfunctions. I have certainly seen stories selected before they are estimated. I have seen stories accepted before they are specified. I have seen stories implemented before they are created. Each of these dysfunctions has it’s own particular set of symtoms and ramifications. What are they?
Thu, 16 Feb 2006 08:12:26, chelimsky, skipping selection Well said, Micah. It’s worth noting that 4 of the 6 milestones are customer milestones. As developers, we want to create the best software we create. We talk about it being a team effort (i.e. whole team, customers, developers, et al), but in the end it’s not really our (developers) software. And how can we expect our customer to feel ownership of priorities if we arbitrarily take the their any (sometimes all) of their milestones?
Building a City
Building software is like building _____?
The common belief is that software is like engineering. Most people seem to think that building a software system is like building a bridge. This is likely the premise that Waterfall was built upon.
| process | Building a Bridge | Building a Web App |
| Analysis: | How Long? What’s it gonna hold? What weather does it need to endure? | What’s the feature set? How many hits? How much data? What platform? |
| Design: | Draw diagrams. Do calculations. Build miniature model and stick it a wind tunnel. | Think about high level architechture. Draw class diagrams. Draw some dynamic runtime diagrams. |
| Implementation | Build the bridge. | Write the code. |
As an enlightened agilist, I know better than this. Building software isn’t like building a bridge. But what is it like then? There is a craftsmanship movement that says software is a craft similar to woodworking or blacksmithing. I believe this is true. However, I can’t say that building a software system is like building a wooden table or a chainmail shirt. Having built both a wooden table and chainmail shirt I can attest the the fact that these analogies don’t capture the depth or complexity in software. So what does?
Cities! Building software is like building a city. No city starts with an analysis committee to decide how may people are going to live there. The population of a city changes over time. The infrastructure of cities is not designed before the city is built. A city’s infrastructure starts simple and evolves over time as the city grows and changes. Cities are not built in one fell swoop. Cities start as small towns and are built up over time as new needs arise.
For those who have had the privilege, think about the first time you played SimCity. Do you remember the first time playing, just trying to figure out the rules. You probably started by building a small residential, commercial, and industrial zone along with a couple roads to connect them and a power plant. It wasn’t long before these zones were fully populated at which point the citizens began to complain about crime. So you had to build a police station and add more building zones. Soon these were fully populated and the citizens complained about other problems. As the needs would arise you had to add a fire station, schools, libraries, and eventually, an airport, sports stadium, and the coveted Archology. That’s how I started.
Although functional, my first city was eternally haunted by pollution, traffic, crime, poverty, and other normal city problems. This wasn’t good enough. I wanted to build the perfect city; A city without all those normal city problems. So I pulled out a piece of paper and designed a city where the industrial zones where far from the residential zone. This avoided pollution. I drew an elegant highway system that was sure to avoid any form of traffic. The city layout was an even grid to evenly distribute police and fire station coverage. It was perfect! I started a new game to build my perfect city. In an hour I was bankrupt. I tried again, and again I went bankrupt. I must have tried a dozens times to build the perfect city and went bankrupt every time. Finally I gave up and reverted by to my very first approach….. start small and build as needed. This more agile approach seemed to work every time.
Building software is like building a city. Start small and go from there.
Mon, 14 Mar 2005 20:19:23, Hui Deng, Yeah, Anything complex will follow the same rule.
Tue, 15 Mar 2005 00:02:08, Kelley Harris, Very nice analogy for software. Adds time dimension and more complexity I like that the city analogy includes the time dimension, evolution, and enough complexity that most people would be struck by the limits of their ability to predict the future. Consider weaving in a comment about the cost of change curve.
Other analogies with time dimension:
- growing a company
- growing a garden
- developing a farm
- developing a network (or the internet)
Tue, 15 Mar 2005 06:14:48, Denis Krukovsky, My wife is an Architect. She’s real Archirtect, she designs houses. She heard words like Analysis and Architecture from me and wondered why I’m professionally using words from her profession. Then she saw my diagrams, and she told me the same I just read.
Denis Krukovsky http://dotuseful.sourceforge.net/
Wed, 16 Mar 2005 00:16:42, Chris Noe, Deeper analogies I like the city analogy. How about exploring this a little further by looking at specific activities in developing a software system. In the evolution of a city, what would be the analogies for:
prototyping refactoring debugging performance tuning configuration management defining requirements database conversion archiving involving stakeholders federating with other systems open source continuous integration backing out a deployment the system has crashed
What city-building analogies might we learn from? Which things do we do better in software? What other software activities might have urban analogies??
Wed, 16 Mar 2005 14:07:07, Joseph Graves, More analogies The usual poor analogy I hear is “building a house” - I once had a contest to try to find 100 better analogies, but I must admit SimCity is quite good. I personally liked Barbecue (as opposed to Ronco Sho-Time Rotisserie set it and forget it software development).
Thu, 17 Mar 2005 14:40:18, MicahMartin, Deeper analogies explored This is interesting….
- ”’Refactoring:”’ - construction. Chicago suburbs are notoriously slow at refactoring.
- ”’Debugging:”’ - This could be a lot of things… Why is Main street so congested? Why does Hinkston Park flood periodically? Why is there so much crime on the south side?
- ”’involving stakeholders:”’ - democracy/voting
- ”’open source:”’ - communes?
- ”’the system has crashed:”’ - power failures, blizzards, hurricanes, …
Thu, 17 Mar 2005 19:56:19, Erik Meade, That’s pretty sweet.
It also helps to explain the tie in with http://www.c2.com/cgi/wiki?ChristopherAlexander the only “real” architect I have met said Christopher Alexander was not well recieved in his field.