Stories and Code Quality

(See also Stories and the Tedium of Iteration Planning Meetings.)

Doling stories out to individual developers not only makes for more boring iteration planning meetings, but it also impacts the system’s overall quality.

One of the most overlooked practices in software development today is review. If you don’t pair, then you really must find a way to consistently review work product. Unfortunately, most companies pay the cost of not doing this: code that is increasingly more difficult to maintain, and solutions that are questionable at best.

Insisting that a team finish a story every couple of days or fewer will often mean that two or more developers must collaborate on a story. In order to collaborate, they must agree on some part of the design and a plan to implement it. The developers will need to continue talking as the implementation progresses. That’s a good thing. Much of the resulting design won’t be one developer’s wonderfully clever or woefully inadequate brainchild.

Such collaboration brings a bunch of siloed developers one step closer to being a true team. Initially, velocity will decrease a bit: developers will have to learn how to talk to each other and coordinate things. Developers will learn more about other parts of the system, increasing their value to the project as well as their personal worth. It’s not quite as good as pairing, but it does go to the heart of agile.

Stories and the Tedium of Iteration Planning Meetings

In “Tools, Iterations, and Stories,” I said you should “focus on implementing and completing stories, not iterations. If your iteration is 10 days, and you have 10 stories of 1 point each, you should have delivered one story by the end of the first day, and two stories by the end of the second day, and so on.”

Then, in a blog post titled “Stories and the Tedium of Daily Standups,” I talked about how a focus on completing stories, not tasks and iterations, would make daily stand-ups interesting enough to bother with (anew–since many teams that initiate daily stand-ups often find them boring and thus slowly stop doing them).

There’s another important side-effect of organizing an iteration around incrementally completing stories: Iteration planning meetings are more interesting.

Implicitly, to be able to complete stories as an iteration progresses requires team members to actually collaborate on a story. Imagine that. It’s at the heart of the emphasis on continual communication in agile, yet many teams tend to miss this key point. In my next blog posting I’ll talk about the side-effect of improved quality. For now, I’ll restrict my thoughts to the impact of story planning on iteration planning meetings.

If an iteration planning covers four stories to be implemented by a team of four developers, there are two primary ways this meeting could go: 1) The customer details each story by focusing on each individual that will work it, or 2) The customer details all stories, discussing them with all four team members. The downside of option #2 is that it will probably take a little longer to work through all the stories. In fact, if you went with option #1, you really wouldn’t need a team meeting. The customer could just meet individually with each developer.

Effectively, what you have with option #1 is a meeting in which 3 out of 4 developers have little interest in the story discussion at any given point in time. Information about other developers’ stories is mental clutter, and consciously or subconsciously, each developer will tune out to some extent for 75% of the meeting. They will view iteration planning meetings as mostly a waste of time.

In contrast, option #2 requires everyone to be attentive. We all have to understand every story, and we most certainly have to start figuring out how each one breaks up. We probably need to do a little bit of design. People attending these sorts of iteration planning meetings are engaged. They leave the meeting with the impression that it held considerable value for them.

Blocked!

Jerry told me about frustrations at his new company. Here’s a possible conversation from my next interview (if there ever is one):

Jeff: Do you block web sites or other things like IM?
Interviewer: We filter on naughty words, we block web mail, and we also disallow use of instant messaging.
Jeff: Interesting. Why do you block web mail and IM?
Interviewer: Because we’ve found that some people tend to abuse it at the office. They also raise some concerns with respect to security.
Jeff: So you also block phone calls, then?
Interviewer: Of course not.
Jeff: Why not?
Interviewer: Well, people have legitimate business reasons to make phone calls.
Jeff: OK, first, there are legitimate business reasons to use IM. Second, you could block calls to individuals’ homes if you really wanted to.
Interviewer: Sometimes employees have legitimate need for personal calls. We find that’s ok if they don’t abuse the “privilege.”
Jeff: So, if talking on the phone all the time was a problem, a manager might intervene and have a discussion with the employee. That seems reasonable. It also seems reasonable that an employee might have a similar, legitimate need for personal emails from time to time.
Interviewer: But we block webmail.
Jeff: Thank you, and have a nice day.

Let’s face it, companies rarely change abusive policies like these. Sometimes, the best we can do is voice our disapproval and vote with our feet.

Test-First vs. Test-After, Round 4

I submit two articles per month to Developer.com. It’s often tough coming up with new article ideas, so coming up with a theme that will produce a long stream of ideas is always a good idea (as long as the publisher is willing to accept it). Design patterns is something I’ve done about a dozen articles on.

Over the nice, long Christmas holidays (vacation for me), I started writing an article featuring the memento design pattern. For me, the hardest part of writing any of these articles is coming up with a good example. I try to avoid the common examples that are already out there, and I don’t think abstract examples are very useful. In any case, once I’ve thought of and coded an example, the article almost writes itself.

Right now, I’m on my third example attempt for memento, which for me is a fiasco. I’ve probably burned eight hours on something that usually only takes me a few. Memento is not something I’ve (explicitly) used, so that’s not helping.

Each example attempt has been centered around the typical use of memento, to support undo/redo capability. I floundered through two examples, discarding each in turn when I decided that it wasn’t a good representation of “real” use of memento.

The other real problem was that I figured I’d wing it. I’ve coded the examples for every other design pattern article using TDD. But over the holidays, I guess I got lazy. For memento, I banged out a solution and figured I’d refactor to something that I could easily unit test after the fact if I felt compelled to.

It’s been a while since I’ve lazed off and not done TDD. As usual, it was a good reminder that it’s just a crappy, less-effective way of working. The code I produced was a mess, with logic entwined in the UI class, as tends to happen when there’s no interest in unit testing. Worse, I kept getting stuck on a problem with BigDecimal and scaling that wouldn’t have given me such trouble had I used TDD.

Maybe I’m just not a very good developer, after all. Or maybe, just maybe, test-after is a less mature way to code.

Atom