Requirements and Dead Cats

Gathering requirements and executing them is not as simple as getting the requirement, then having someone code it. It's like Schrodinger's cat. That's the problem where you have a cat in a box, and you don't know if it's dead or alive. Theoretically, the cat is both dead and alive at the same time.

If you wait long enough, the question answers itself. The cat will always croak.

Every time a requirement is touched or thought about after its creation, it changes. Instead of the cat being dead or alive, we're not even sure if it's a cat. Maybe someone put a chinchilla in the box. The req is perverted in ways that, at the end of the development period, are beyond human comprehension. Ironically, the simpler the requirement, the more perverted and complex it becomes. A two-line requirement, I swear, will become something that can bring down the very foundations of our society if we ponder it too long.

Note: this is the true goal behind agile development: to keep us from thinking too long on any requirement, lest we all be destroyed.

Longer requirements are perverted less, but not because they are more exact. We simply do not like thinking about them. Put them in a ticket, and it's guaranteed that we will not open that ticket until week six of a six week development cycle.

This is a real problem in large buy-in groups like mine. We have lots of people who like to touch tickets all the time and think about them and morph them from dead cats to live ones and back again. Here are some of the ways tickets are perverted:

• Comments on tickets


• Comments on the comments on tickets


• Comments on the comment on another ticket


• Conversations had in meetings, dutifully noted by the meeting note taker


• Conversations had at desk side, sometimes followed up by a confirmation email


• Conversations had in the hallway, where one person is pensive and filled with ideas, and the other really, really has to pee


• Alternate universe conversations, in which one person has one conversation, and the other person has a completely different conversation


• Imaginary conversations, in which one person will swear they had a conversation with another person, and that person swears it never happened

So, what do we do?

Well, we're getting better about it, for certain. And I'm trying to introduce some things that will make the perversions cause fewer fist-fights at the end of a dev cycle, when I'm calling for a tag to be cut, and buy-in people are screaming for an extension.

Fewer requirements

At first, this seems counter-intuitive. Wouldn't more tickets give more of a buffer to the poking and prodding of any one ticket?

In fact, part of the perversion that goes on is due to people having so many tickets to touch. They touch one, then run off to touch fifty more. By the time they've returned to the first ticket, they've forgotten how they changed it the first time, then change it again.

Having fewer tickets means giving people the chance to actually remember what they wanted the first time, and keeps the developers from having to change code in fifty places every time someone decides to walk through the requirements again.

We do not talk in N-Space

If a conversation isn't recorded in a sensible location, it did not happen. I do not care if the President of Burundi is willing to vouch for you: those words were never said.

What's a sensible place? Oddly enough, it's not 'the wiki.' 'The wiki' might as well be synonymous with 'the trash pit' or 'a teenager's bedroom,' the way most people treat it. It's not 'the meeting notes'. No one refers to those things unless they want to prove you wrong about something. It's on the ticket where the requirement is. If you have a conversation, record it there. Not in another ticket. Not on a new wiki page. Not in an email that no one else will see. Not in some word document on the server.

On. The god-damn. Ticket.

Vicodin

As I said in the previous post, requirements getting perverted happens. Most of the time, the differences are minor. A satellite is not going to fall out of the sky because the navigation on a web page isn't indented quite enough.

When a requirement isn't quite hitting the peg for that release, and not everyone who has buy-in is loving it, don't hit the pause button. Momentum is a thing that's hard to rev up, once stopped. The second you hit the 'OMGWTF' button, the entire group's memory starts to decay, and, as they review the tickets that were closed until now, requirements get even more perverted.

Take a pill. Sometimes you just have to try again.

Cut a tag and try again

If your cat is indeed dead and smelly, cut a tag and start working on the next cycle. Non-developers don't know this, but cutting a tag feels good. It's like the feeling you get when walking into a fresh hotel room. The sheets are fresh, the soap is wrapped, you've got little bottles of shampoo, and everything is clean and shiny.

Give your devs a new hotel room. Cut a tag, and start over fresh, rather than hoping to squeeze one last change into a beleaguered release. Because if you look at the requirement too much, it does bring about the end of all things.