Hot Needle of Inquiry

… sometimes they’re popular because they’re easy.

1. Sorry, everyone, I just couldn’t resist.
2. Sorry, women, but as I see it it doesn’t cut the other way.

However, in all seriousness, there’s a lot of stuff that you have to do beyond what’s in the Scrum literature if you want to be really successful. I freely grant that a clear understanding of obstacles, and working to remove them, will pretty much get you there. Or you could pick up a book on Extreme Programming …

On the agile-usability list, Jeff White pointed to Jeff Patton’s article, Twelve emerging best practices for adding UX work to Agile development. He asked for comments from the “more traditional agilists”. I’m not sure how traditional I am, but I commented as follows:

I think it’s just fine, and coming from Jeff I’d expect nothing else. Items that made particular sense with me:

1. Drive: UX practitioners are part of the customer or product owner team

Of course. Otherwise they’d have to be part of the technical team. But then the customer / product owner is hampered in making the necessary tradeoffs between UX concerns, price concerns, and timing concerns.

4. Use parallel track development to work ahead, and follow behind.

For best flow, the customer-side people always need to work ahead and follow behind in Agile. Naive teams try to jam all the customer planning and disposing into the same iteration as the work is done in. This is often called mini-waterfall, and it works no better than regular phased waterfall, and is less interesting because there’s less water crashing down like thunder.

I envision what Jeff is talking about here as a sort of refinement process. Looking a few iterations out, UX people sketch what needs to happen. Looking one iteration out, they define actual work that needs to be done next iteration. Looking back, the observe the result of what they’ve asked for,  and determine changes.

Perhaps this needed to be said. If so, it needs to be said for the whole product-owner community, because it is exactly what any product owner needs to do.

5. Buy design time with complex engineering stories.

Yes. UX matters really do not pervade every line of code one writes in an application. Under one UX button click there can be a mass of code — and that mass of code can just as well support the UX hand-wave or UX cough or UX eye-flick that will be the ultimate interface.

The operations of the application will always be pretty much the same, though how they are threaded together may vary. Good system design makes these operations modular anyway. Therefore there
probably are complex engineering stories available, and doing them is probably safe.

Caveat: Jeff calls these “engineering” stories. I would not, just because they do not have UX aspects, let this idea justify “technical” stories. On the contrary, these are the guts of value-bearing stories. The example he gives of the Sketchbook File Save / Load is a perfect one. This is a feature, not some technical enterprise like define a database or build a file system. And so it should be. Stories should always be value-driven.

It’s all good. As whatever level of Agile Guru, Agile Curmudgeon, or Agile Jerk I might be, I approve Jeff’s message.

I’m reviewing Janet Gregory and Lisa Crispin’s forthcoming book on Agile Testing and ran across the title line in the middle of the text. I answered immediately, drawing the unwelcome attention of all here in the Borders Coffee Shop:

SHORTEN THE ITERATION!!!

No, really. If this is happening, your iteration is surely at least a couple of weeks long, maybe a month. Odds are your stories are too big anyway. Size down the iteration and size down the stories to match.

You’ll be glad you did.

Track the Impact

OK, I suppose it’s possible that you could get your iteration size down to a week and story changes would still come up. The fact that I’ve never seen it happen doesn’t mean that it couldn’t.

A certain amount of story changing may be due to the Product Owner or Customer not thinking quite hard enough about what to ask for. (This is only true if your iterations are short, by the way. If they aren’t, that’s the problem, see the first item here.)

Changing one’s mind about the story costs time, and time, we are told, is money. So, if this happens frequently, consider making a big visible chart of lost time. To be fair, track other forms of lost time, not just this one. It might turn out that this isn’t your biggest problem.

Mainly, though: shorten your iteration. You’ll be glad you did.

Most of us who work with code have worked with code that slowed us down. Many of us have worked with code that was so bad it made us want to give up on maintaining the code at all. Some of us, to our shame, even wrote the stuff.

Many of us have also worked with code that was easy to change, that seemed to want to change to do whatever was needed. And to our shame, over time, we may have converted this lovely malleable code into stiff unresponsive unmaintainable code.

Looking back at code that is hard to change, and comparing it with code that is easy to change, we can usually see that “Mistakes Were Made”. These mistakes accumulate. The modern phrase for that accumulation of evil is “Technical Debt”. What causes technical debt and what can we do about it?

Technical Debt == Bad Design

There it is, bluntly and simply. Technical debt is bad design. Good design is modular: It has each discernible bit of design in a single place, not spread all over. Good design is not repetitive: each design element is used repeatedly, not copied and bashed into each new application of the idea. Good design is expressive: if a useful design idea was in your head, it is visible in the code. Good design is lean: it does not unnecessarily multiply elements.

Readers will recognize here a rephrasing of Kent Beck’s description of simple code:

1. Runs all the tests;
2. Contains no duplication;
3. Expresses all the design ideas;
4. Minimizes the number of program elements.

What we want is code with every idea in its place and a place for every idea. What we have in a situation of technical debt is … not that. We all know how to recognize it when we see it — or when we finally see it — because we don’t always notice the trouble before it is too late.

How can we recognize technical debt sooner? What should we do to prevent it? What can we do when, after all our best efforts, we wake up one day surrounded by the stench of rotting festering code?

Preventing Technical Debt

Let’s Not Push So Darn Hard

When we push to go fast, we miss things. We may even notice them, but we’re too busy right now to change them. Maybe we make a note, maybe we just let it slide. At the end of the session, the world is just a bit dirtier than it was when we started.

Let’s Play Our Best Game, Always

Everyone surely has a set of personal practices that leave code better — and practices that let it deteriorate. In principle, we can always use those practices. In practice, we may not always know how, and we may just let things slide for one reason or another. Personally, I believe that development always goes faster when I work in “full quality” mode, even over the very short term.

Let’s Always Be Ready To Stop

At the end of the day or the session, we may feel pressure to stop. We may decide to leave the code just a bit smelly, thinking will clean it up next time. Yeah, right. That’s why my desk looks the way it does.

Speaking of my desk, I’m now to the point where a major refactoring seems like the only way out. I’ll think about that later but let’s imagine that I get it clean, somehow, magically. (I could do my desk by sweeping everything into a nice plastic box. I could dig into the box if I ever need anything from the desk. But for now, imagine I get it clean.)

What if, every single time, when I use something or receive something, I put it where it belongs? Every single time. My desk would be clean, every single time. There would be at most one thing on it, still in process … uh oh! Watch out! When I come back, maybe that won’t be the thing I work on. Then there will be two things. No, no, stop me. Every single time, even if I’m going to come back to it, what if I put the thing away.

Wow, clean desk! Can I do it with my desk? Can I do it with my code? Maybe not. But can I improve my habit of being always ready to put my work, and my code, away? If so, it would surely help.

These Tricks Never Work

OK, Captain Morality. All these thoughts on keeping things clean are great. But I happen to know that you aren’t always able to do it, and there’s no one riding your back to do another feature. It’s just not realistic to imagine that people are going to have enough discipline, always, to keep the Technical Debt Kneecapper away from their door.

It seems like there is going to be debt even with fresh code written with eyes open. Besides, a lot of us came in in the middle of this movie and there is already debt built up. Do we live with it, or do we pay it back? What’s our best strategy?

Repaying Technical Debt

There are a few ways of recovering from excess technical debt. Along some spectrum of hugeness, we might see rewrites, major refactorings, and incremental cleanups.

Rewrites

Most of us have seen a program that was such a mess that the only thing to do seems to be to start over. In my opinion if the existing program works at all, this is almost always a bad idea. It will be a long time before the new version is good enough to replace the old, and all that time someone will be paying for us to program, but receiving no benefit. This tends to make them tired. In addition, it’s really no fun slogging away like this.

Not recommended.

Major Refactorings

When rewriting the whole thing isn’t acceptable, sometimes people want to undertake a “major refactoring”. They want to spend a bunch of time cleaning up the code, then to return to delivering features. While this isn’t as bad an idea as rewriting it all, it smacks of the same thinking and has the same drawbacks. Someone is spending money and getting no benefit.

In addition, it’s awfully easy to dive into some refactoring and never come up: “Our refactoring failed.” This is especially true if we don’t have lots of solid tests. And we haven’t, have we?

Not recommended. If you must, try Strangler.

Incremental Cleanup

The approach here is that when we are doing a story in some area of the code, we clean up that area, using some amount of time that is proportional to the time it will take to do the story. Maybe if the story takes a half day, we spend another half day cleaning up. In this way, we continuously offer stories, and we improve the code in areas that are more likely to be visited again, because they are being visited now.

We don’t rewrite the area; we don’t spend days in there for a two-hour job. That’s disproportionate in my opinion. We just make the place noticeably better than it was when we came in.

What if every time I came into my office area I cleaned up one item, or as many books as I could grab in my hands? Might I not make progress? I think I would. Hmm … I’ll try it.

Strangler

If (and it’s a big If) we really need to replace some system, consider using a strangler kind of approach. The basic idea is to write new bits of the application, and put them in place so that they replace the old equivalent bits. Over time, all the important bits wind up being in new code.

Bottom Line

At this moment, I don’t have much more of a “position” than this:

• Technical debt seems like a good metaphor for the cruft that builds up over time;
• The best thing is to avoid it as much and as long as we can;
• Avoiding technical debt requires a level of discipline that is hard to sustain;
• Repaying technical debt is best done incrementally — any other approach is, in my opinion, usually suicidal.

I’d like to know more. I plan to think and listen until I do.

It seems that whenever a politician modifies his or her position on something, they are accused of “flip-flopping”.

Maybe I’m unique in this, but I would like my leaders to be continually evaluating the situation, taking in new information, observing results, and changing their views and their actions.

Seems to me that “Stay the course” is a bad strategy in most every endeavor. I’m more into steering.

There’s nothing like a bean counter when it comes to improving your shopping experience. Take Borders, for example. In their little coffee shop, a captive Seattle’s Best Coffee, they have things to eat. These are not to be confused with food, mind you, especially the bagels.

They used to have bagels that were clearly imported from a real bagel place. They weren’t great but they were really bagels. Now they have round donut-shaped bread things that they bring right from the refrigerator to a counter near you.

Someone at Borders HQ doubtless said, in a very expensive meeting, he said “Now look here. We are paying 40 cents for these bagels we sell, and we’re charging only 75. That’s for plain: in my analysis cream cheese has been factored out. We have to select bagel type and if we get it wrong we don’t sell them at all. We can ship these new Official Borders Plain Bagels from our warehouses in Elbonia, right to the store, for only 35 cents each. Because they are all the same, we’re never out of the kind the idio excuse me customers want. We can up the price to 80 cents, and of course the cream cheese is extra and that’s pure gravy heh heh. Over all our stores, all our customers, and over all time, this will increase our profit on a per-bagel basis to 40 cents. There will be less wastage and we may be able to save even more if our experiments in bread compression work out.”

Some poor bastard in the back of the room may have asked “How do they taste?” If he did, the answer would have been along the lines of “Thanks for your intelligent question, Jensen, it shows real creativity on your part. I guess I wasn’t clear: we will increase our profits here by millions of dollars over the lifetime of the sun.”

Well, Jensen was onto something. These things don’t even look like bagels and I sure as hell don’t intend to taste one.

Another victory for bean counting. And one step closer to the grave for Borders.

I wonder if Amazon can send me bagels …

Test-Driven Development checks intention. Customer Acceptance Tests check desire.

When a programmer uses TDD, she knows what the customer desires. She thinks about what she intends to make the program do next, as a step toward what is desired. She checks that it does not do that, then makes the program do it. She is using TDD to help direct her intention and to check that she has accomplished her intention.

The customer knows what she desires. When she provides acceptance tests and examines the results, she is checking to see whether she has received software that meets her desire.

This may seem like an awfully find distinction and, who knows, in a day or a year I may have or hear a better way to put it. But the customer acceptance tests are about the goal, and the programmer tests are about the path to the goal.