Agile Otter Blog

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...

A friend rightfully takes me to task: The anti-cleverness you describe is anti-badness. I think we all can agree that bad is bad. But you and most of the other anti-clever crusaders have no definition for it other than it made your life miserable or you at least don't like it. And then you assume someone you never met thought they were being smart. That's where your ice gets really thin. You weren't there and you don't know what the constraints were at the time. And what really makes it irksome is that you have a whole library of well defined "bad code smells" which are a lot more specific. Why don't you use those? Those have meaning and in many cases they have remedies. It comes across as smug blaming of the guy who left, and dirties what I've observed is an otherwise a healthy data driven approach. See, I like it when my friends help me keep it honest and real. If one wants to improve, one must remain introspective and consider feedback when it is g...

There is a cool outgrowth from James Carr's collaborative paper on TDD Antipatterns. There is a Stack Overflow article where you can vote to determine the most prevalent of the ugly smells. I was a little pleased to see "Free Ride" as the number one last time I looked. Just pride of ownership, I'm not glad it's common.

I really don't want to make this sound like a big deal. The whole thing happens in less than a week and really only affects a handful of files. Nonetheless we went through the gamut of emotions common to maintaining ugly code, and used a range of tools common to trying to do a craftsmanlike job in a legacy code base. Even with a small task, it can be a challenge to stay engaged and positive. I'm working with a good partner on some bad code that wraps some SQL and does some dynamic web stuff for reports. If we were working in SQL, we could have written the query and been done with it. Even if it were SQL and a pile of if statements it would be comprehensible. The problem is that the code is clever and complicated. The people I work with have cleaned it up considerably from its original consultant-delivered form. We got to work with the good version. It is a rather clever framework that hides the SQL behind a report by causing you to write chunks of SQL as literal string...

If you want an estimate of the cost of making a bad prioritization decision, try this cute little calculator .

Here's one for you. Given two boolean variables A and B, and a language where booleans are real types and not masqueraded integers, consider this: if ( ! (A ^ B) ) { do_something(); } Think about how you would have written this two-bool operation. Laugh with me.

Our office firewall gets in the way of Yuuguu , probably by blocking UDP traffic I'm not sure what the real . Finally a coworker was WFH and we were able to try it. Hey, it worked. Lag wasn't bad, control wasn't hard to trade, and it didn't really get in the way. It really shared the other guy's screen, not just certain windows. That was very convenient, but it also meant that I could see his IM and email notifications and the like. If you worry about such things, be warned. OTOH, it means that he could pop up editors, SQL tools, log tail programs, and the like without having to explicitely share them with me as he as to do in webex. Yuuguu didn't include voice, but included a voice conference line. It does nice instant messaging and screen sharing, though. We skyped for voice, and yuuguu-ed for screen share. It can tie into your instant messaging accounts, which makes it easier to find people you know. We had work to do, so we didn't spend so much...

My talk on remote pairing with Tim Gifford was accepted for Agile 2009. My talk on the In A Flash cards was not. Ah, well, ya don't win them all. See you for some of the Wednesday fun at Agile 2009.

I'm not typing a lot of blog this week. I'm typing more web searches and notes and stuff. I'm learning more about memcachd and tuplespaces and couchdb and DVCS, hanging with the offspring, and cleaning code. It's a busy time and I'm learning much. Hopefully I'll be contributing at least as much. We'll see.

Overall, this is not a bad process. When we're truly engaged and the bandwidth is good, and we don't have the same partner too long, it's a very workable arrangement. Overall, this is a good way to go about things. At least 80% of the time, it's great. There are a few issues that go into the 20% times when it is less than perfect. Sometimes we can hold meetings well. Other times, the person on the phone is being left out. It is hard to hear the voices well, and forget about reading the whiteboard. If we're together, and can stay focused, and can keep chatter down to one voice at a time, and can keep background conversations quiet, then meetings work quite well. It's really a lot of effort on the part of the physical participants to stay attentive to the needs of the remote. I miss a lot of it. Face it, long distance may be the next best thing to being there, but it's a distant second. At least where meetings are involved, this is second-best. It also ...