Paper Bullet
Work has me visit lots of software teams around the world. This past week I visited a particularly fun team. They worked in a large open work area with desk space for pairing and wall space for BCV (Big Visible Charts). Anyhow, there was one member in particular, I’ll call him Dan, that was notorious for his mischief. Most notably, he’d start paper bullet wars.
Paper bullet is not the term they used but that’s what I’m gonna call it. What you do is tear off a piece of paper and roll it lengthwise. Then fold it fold it in half so you’ve got a wedge shaped paper bullet. Then take a rubber band and stretch it between your thumb and index finger. Slide the wedge onto the center of the rubber band, stretch, aim, and release.
Dan had apparently surprised everyone on the team with a paper bullet in the face or neck at one point or another. They held a friendly grudge against him.
Early in the week I was unaware of the paper bullet wars and I found it peculiar that there were all these bit of paper on the floors and desks. Apparently wars were taking place all week but, being the guest, no one wanted to hit me and so who ever was pairing with me had immunity.
In the final hours of the last day they confessed at how nice they were and how lucky I was that I didn’t get shot all week. Frankly I was disappointed that I didn’t get to play all week so I spat out some fighting words… “You’re lucky you never got me involved!”. It began. I could hear them whistle past my ears as I was writing so unit tests or bounce off the wall behind me as I pass the keyboard to my pair, but I never got hit.
Thankfully, other team member armed me a rubber band and a hand full of paper bullets. At a quiet moment, I figured I’ve give this game a try. Grabbing the rubber band and paper wedge, I loaded and aimed right at Dan’s head. The rubber band was surprisingly flexible. Not knowing how hard to stretch it, I just kept pulling. As I looked down the trajectory, I was sure the projectile would curve. When I released I was shocked and horrified.
The bullet screamed across the room, straight as an arrow, pegging Dan right in the side of the head. It made a loud smacking noise upon impact. The whole team heard it and the room went silent. I was terrified. This was no way to treat your clients, I thought. The poor guy never even hit me so he didn’t deserve it. Apparently I was wrong. Everyone else thought he deserved it. The room broke out in laughter. Team members (not Dan) gave me a thumbs up, telling me “Thanks” or “Good job”.
I apologized to Dan later, trying not to stare at the red welt just below his temple. Dan, the sportsman that he is, congratulated me on my marksmanship. He’s a good guy.
So what’s the moral of the story? None really. But I will note that many of the development environments I visit are much more sterile and “professional” than this team…. and much less productive as well.
Wed, 19 Apr 2006 10:21:32, Greg, hey !? Did you visit my office recently and I didn’t know? We’re also doing this, but since there’s only 3 of us in the office, we sometimes have to use other targets than ourselves (when the red marks are becoming too obvious). We just destroyed an ugly dummy cd of some bad dutch singer here.
Wed, 19 Apr 2006 02:52:29, Mike, My mother used to say it’s only fun until someone’s eye is put out!
Tue, 18 Apr 2006 10:49:47, Dan (yes that one), Injury update The swelling is down…I can see out of that eye now…hope you come back soon :) :) :)
Tue, 18 Apr 2006 06:44:08, Ryan Platte, Nice shot! Don’t be surprised if I hang out by a pillar if you come to another Chirb meeting, yikes!
Fresh Testing
Sometimes I sit down to write a test on something I haven’t worked on before or don’t know intimately, and I just can’t write the first test. I need a context of the system and a state of existing code. Then I generally do one of two things: look at how things are implemented in the code, or look at other tests that exercise similar behavior. Using either of these as a strict model to write a test is problematic to the flow of TDD.
By using the implementation code as a model, I am limiting one of the great things about TDD from the beginning, the fact the design should evolve as a byproduct of making the test pass. This TDD complacent method tends to ingrain existent design into my mind. These strict models resign to existing design, even if your story/test/problem isn’t exactly the same, just similar enough to convince you of the model.
Copy/pasting a similar test and editing is a developer mistake I commit sometimes when it looks like a freebie is being tossed at me: duplicate then abstract. It is very tempting, yet I have found it painfully regressive. Especially when the tests themselves have begun to rot, as their ability to act as developer docs are deprecated. It causes a lie in logic which is always painful. Either the debugger gets fired up or the test gets scrapped in order to handwrite anyway. Copy/pasting something which is similar is starting from a false expectation most of the time. It is more important to me to have faith in the integrity of my tests.
The most powerful TDD I see is at the beginning of a project, since there is a state of tabula rasa allowing you to move infinitely lateral. Before tests depreciates provides the best model for TDD. Test depreciation is unavoidable, as with design changes, the tests are changed with regularity to accommodate the new structures. The reason for having the tests is to have a safety net to make the code easy to change. It becomes important to keep tests “fresh” when there is already design in place. Otherwise good design appears to degrade due to over/improper use.
Handwriting a test from scratch can seem like an extra step, like reinventing the wheel. Most of the time the extra step is exactly that, an extra step, but in those cases where you are following a false model it is very expensive. It introduces the worst type of design into the system, the kind with little to no smell, but with false premises. Introducing bad design into tests or failing to maintain test code ends up introducing bad design into production code.
COMENTS
Thu, 5 Jan 2006 22:16:48, David Chelimsky, copy/paste Copy/paste can be a real problem, yet it takes an awful lot of discipline to abandon it completely. For example if you’re test driving something new - you write the first test which has some setup in it. You’re not ready to move stuff to a setup method because there’s no duplication to warrant it yet. So for the second test you copy/paste the first test, modify what you will, get it to pass, and then refactor out the duplication. With just a few lines of testing code that’s probably acceptable, but there’s a point where you get yourself in trouble. I guess that’s different for everyone, and perhaps on different days (depending on the coffee/sleep ratio). Maybe committing to a day of absolutely zero copy/paste to see if it really slows me down would be worthwhile.
Thu, 5 Jan 2006 22:53:53, Tim Ottinger, What he said I hate copying from any existing tests, always feeling like I’ve cheated somehow. It is a way to get by (or try to get by) when you don’t really know what you’re doing. When I talk about whether I [[really know][http://tottinge.blogsome.com/2005/12/30/how-can-you-not-know-java/]] something or not, I consider whether I can work from the blank slate. If not, then I don’t really know my topic. Not only is working from tabula rasa liberating, it’s a good indicator that you’ve done enough backgrounding. It’s good on so many levels.
I just wrote the other side of this blog, that [[naive tests don’t help][.ArticleS.TimOttinger.NaiveTestsDontHelp]] so you have to know the software to write tests for new parts. I think that it would be good if we could work on the pro/con of this and give guidance on navigating between sylla and charybdis. If you don’t know enough, you can’t blue-sky the tests. If you are copying the tests, then you only reinforce the implementation in testing (for better or worse). There has got to be a middle way, and some heuristics to help get around: something more useful than “pairing should fix that.”
Fri, 6 Jan 2006 15:50:00, Thomas Eyde, Copy/paste is for professionals – don’t do that at home I think the trick is to write the tests for the truly new requirements, then find reusable code if any, or refactor existing code to be reusable. Not easy, but that’s what I strive for.
I also think there’s nothing wrong to copy/paste and then refactor. It’s without the refactoring things start to get dangerous.
Sat, 7 Jan 2006 12:28:24, Matisse Enzer, Copy and paste as an iterative action Yesterday I was adding tests to some “legacy” code. After I got the library to compile under the test harness I picked one subroutine to test, and create d a test to run that subroutine. Of course I got a run-time exception because the subroutine I was testing made a call to a subroutines defined in some other library. So, I created a stub version of that subroutine in my test harness. ran the test again, another missing external subroutine. I copied and pasted the stub I had created, changed the name, reran the test. Several times. Each time adding a single “fake” subroutine. (Sometimes I had to edit the stubs to return some mock data.)
I also copied-and-pasted my first test. Renamed it, and changed the arguments it passes to the subroutine I’m testing. Did this three times.
Mon, 30 Jan 2006 22:46:53, Paul Pagel, the copy/paste problem There are many ways to introduce code debt into a system. Duplicate code is one of the worse. Copy/Pasting leaves the payment of this debt to the memory of the developer. So if it is copy/paste a few lines at a time, then refactor at the end of small cycles, then I go for it. But if it is going to be coping a file or a series of tests/methods, I won’t.
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?