My baby bird metaphor
Here’s a metaphor I use a lot. Let’s assume we’re doing some sort of process where some people (call them “testers”) provide examples that another set of people (call them “programmers”) realize. By “realize”, I mean they change the code so that the examples, which were previously examples of something the product doesn’t do, become examples of something it does.
Most often, there are more programmers than testers.
What I tell teams is that I visualize the programmers as many baby birds in a nest, all chirping “feed me! feed me!” What they need to be fed with are examples to realize. The testers are the harried parent birds, zooming up to the nest, dropping a grub (a test) into a programmer’s mouth, then zooming off in search of another grub because—oh no!—another baby is about to finish its meal.
I tell this story for two reasons:
-
It captures how harried testers (and product owners) can be on a team. It encourages the programmers to have a little sympathy.
-
Just as the parent birds don’t stockpile all the grubs they’ll ever need in advance, the testers don’t have to have all the tests for a story done before delivering the first one or first few to the programmers. As long as the next test is there when the programmer needs it, all is well. In fact, finishing the next test just as the programmer finishes making the last one pass might be most efficient.
It’s just a metaphor, and has some imperfections. For example, there’s more to it than dropping tests onto programmers’ laps. There’s also discussion of what the whole story’s about, etc.
January 25th, 2009 at 1:57 pm
What a great way to visualize this. Here’s my extension into the metaphor imperfection you state at the end:
Until the nest is crawling with bugs and the baby birds look for a new nest or are shoved out of nest overtaken by grubs.
Apologies to extrapolate metaphor too far, trying to highlight ideal of work acceptance, aka pull. Little birds are too immature to get food on own…
I also like the way that you give the CC credit (instead of photo caption) and will include now on my site. Do you leave comment at the picture that it is being used?
January 26th, 2009 at 2:44 am
Great metaphor! But I wonder, as good as encouraging sympathy is doesn’t it really miss one of the major things organizations gets wrong in this case?
The problem isn’t lacking sympathy from the “programmers” it’s the organizational make-up that forces testers,business analysts and programmers into such an unbalanced relationship. Or at least that’s how I’ve come to see things from this programmer chair, as a consultant the majority of projects I get to work on are programmer heavy leading to vast amounts of “done” code laying in piles all over the place, over-worked testers and customers experiencing lead-times that are to say the least shocking. If something takes two weeks to code the customer has to wait 3-12months for it to be depoleyed the organization can hardly claim that they’re low on programmers, still they do.
January 26th, 2009 at 11:11 am
Torbjörn: My personality is bottom-up. While it’s often true that the larger organization or system is what really needs to be changed, I usually don’t have either the opportunity nor skill to change it. So I work on the team, hope success speaks for itself — and, since it often doesn’t, hope someone else works on the organization.
January 26th, 2009 at 9:39 pm
I have yet to see a programmer who likes the testing phase. Programmers hate doing the testing, and also hate the testers (they’re frustrating with their never ending bugs that delay the project from getting finished). I do not really agree with the “Feed Me” thing.
On the other hand, and oddly enough, programmers like fixing bugs once the software is released. Even as a Project Manager with programming experience, I have no idea why (or maybe I can’t remember why).
January 27th, 2009 at 1:34 am
PM Hut: As a programmer by trade my personal problem with testing is that I’m quite crap at it. Im fairly good at unit level testing, that is validating that I built stuff right. But Im horrible at getting ideas like filling up the disk just before starting a resource hungry operation, janking the network cord in the middle of a transaction and trying to run my software on Windows ME. “Testers” seems to dream about stuff like that though. Testers, QA’s, BA’s are great for handling and defining acceptance and interaction tests and thoose are what I want them to feed me because that adds the dimension of “Have I built the right thing?” to complement “Is it built right”.
I think most of the friction between testers and programmers are artificially put there, if everyone is working under an “agressive schedule” who ever is last will start way behind and anything they do will invariably irritate everyone else. Testing early and often seems to in my experience combat this tendency.
January 30th, 2009 at 12:16 pm
Apologies if this is too far off point…
“Chirp Chirp” was one of my favorite responses when a dev didn’t think there were getting enough examples and/or good enough examples. However, we’ve started a process recently where testers become the BA for the devs for a moment, and the devs then help build automated test tools in a pairing setup. The results have been extremely positive. Both sides get more mutual appreciation– the dev gets better test reports, and the testers now have better throughput (and more cool toys for breaking things.) The only problem was that some of the “birds” didn’t like the diet and resisted participation.
January 30th, 2009 at 9:05 pm
The thing is, in my opinion, is the never-ending bug. As a programmer, I’m sure this happened to you:
- The tester reports a bug
- You know that bug is hard to fix, so you fix it with disgust
- The tester tests the application, and says that the bug is fixed
- The tester reopens the bug, and tells you that under certain conditions, it’s appearing
- You fix it again, though you’re frustrated this time
Note that the above scenario can repeat multiple times. Eventually, the programmer will feel that the tester is picking on him/her, and the issue will become something personal (I see it all the time btw).
I like you solution for the problem btw.