Agile Otter Blog

Mike Hill discusses How TDD and Pairing Increase Production , and he is right. Today, two of us have been working, and have made progress, but the reality of the situation is that we've only commented out a few lines of code and run the debugger. Neither of us have worked in this code before, and there are no existing tests. Just finding our way is work. Real work requiring attention and sifting through many facts for the few that give us a clue as to what is not really working and why. We're spending the day (so far) reverse-engineering older code and trying to understand how (and whether) to make our change. Programming is largely about thinking, planning, scheming, and not making mistakes. I do those much better with a partner.

She (rightfully) hates the sandwich technique , where you build your criticism into a protective fog, to keep your colleague from feeling like you have criticized him. Which you have. But now he's not sure. Or, I suppose, it would mean that you mix your praise for his good behavior with criticism... to keep him from getting the swelled head? Whatever. I think I'd like to know if I'm effective. Even when I was feeling very self-conscious and unhappy, I would take criticism because I want to be better. I prefer "don't do that" to "you know, you're all really good person and make good hot sauces but...." I guess it takes all types. In IT/Software, I would suppose many of us follow some older, wiser advice .

I always find I do a better job if I top-down my tdd work. I have a good context, goals are clearer, and the strategy doesn't get lost in the tactical work. It's such a good way to work. On the other hand, I find myself constantly battling the urge to bottom-up the solution (and losing fairly often). When I bottom-up the work, I risk having a solution that doesn't really work in context and I have more rework. So what is the pressure that makes me want to bottom up? I think it's because TDD is easiest when you are closest to a unit you're testing. It is easiest to isolate, and the tests are smaller and more clear than at higher levels. In addition, you never have a higher-level red test to ignore (or I've seen people comment them out) while you get a lower level test working. I also think it has to do with the human "optimization drive" to skip all the navigation and jump to the file we think we'll have to change anyway. Maybe this is stronge...

A friend just pointed me to twiddla as an online whiteboard for remote collaboration between friends and colleagues. I diverted a little time from work and went there this morning for about 15 minutes. Looks like it could work just fine.

I guess I didn't read enough of the literature, but was tickled when I found this little blurb at American Way Magazine : After 12 years as a programmer, Kent Beck understood that there were bugs in the conventional approach to developing software. But it took one particularly rancorous gig for Beck to decide that there had to be a better way. The project’s manager was “a tin-pot dictator” who pounded the table as he abused his programming staff, Beck recalls, blaming them for problems that were systemic. By the second day on the job, Beck became furious — and was escorted out by the company’s security force. But an idea born in that confrontation would flower into Beck’s new strategy for software. He calls it extreme programming (XP), and it has attracted acolytes around the world. Beck has written a manifesto called Extreme Programming Explained: Embrace Change and has founded a nonprofit, the Three Rivers Institute, in Merlin, Oregon, to spread the XP gospel. I guess sometimes i...

I just wanted to enshrine these words of Kent Beck before they're lost in the aether. Read carefully: Another purpose of measuring capacity is to improve throughput. If you plan for less than your capacity, you get less done than you could have. If you plan for more than your capacity, you get less done than you could have. Having a plan with "enough" work in it less some slack to improve the probability of meeting commitments increases the amount of work that gets done compared to planning for too much or too little.

Corey Haines recently posted a note to the software craftsmanship mailing list about definable process. What I love is the repetition of the phrase choosing the 'most convenient' place to put the code, rather than where it actually makes sense I have fallen victim to this. Rather than trudge through the code to make something explicit, we looked for the most convenient point of code insertion. Even while my partner and I talked about how it felt too implicit and a little "clever", we tried anyway hoping it would save us the cost of tracking down the places where the code was needed. It turned out to be too clever by half (at least) and got us into a mess of indirect recursion and ugliness. Eventually we figured out how to have the compiler & tests tell us where the code was used so we could make changes explicit in their context, and this took us all of an hour maybe. It was a small cost, and left us with a more explicit answer. Of course, it also meant that...