Agile Otter Blog

We had a nice talk today about the natural foot-dragging that is common among pair programmers when it comes time to switch partners. It's not really social, as in partners gravitating to each other as buddies. Instead it tends to be more work-related.  It does feel socially awkward to tell your partner you want to go work with someone else now. It sometimes does happen that partners who are gung-ho agilists will prefer working together. They prefer partners who allow them to do their work well and will improve them over those who create drag by arguing against testing or refactoring. People get comfortable in a particular task and want to see it through.  This is a good feature usually, and certainly is favorable for people who do individual, non-paired work. In an agile team, it's limiting. Someone needs to move on so that there are more eyes/hands/minds in the code. If there is no standup there is no pair switching.  If the team relies on assignment from a manage...

I've been developing new skills, and working with Jeff on the AgileInAFlash project . What's new? Our latest article for Pragmatic Programmers.

Vadim reminds me that I need to address root causes of Copy-Paste-Edit programming, rather than merely ranting about how bad a practice it is and how it ruins good code . Of course, he is right. That is part of being Vadim. I've previously ranted about the ill-effects of copy-paste-edit programming, but it would be unfair to say that there is never a need for it, or that people who did it were simply stupid and lazy.  The problem would not be so prevalent if it did not have some reasonable basis for practice. However well-intentioned and useful it is, its net effect on a code base is overwhelming negative. Here are a few root causes I recognize, and I'm open to hear more. Tedious construction semantics encourage copying. Many APIs are very thin access to bean-like objects, and yet using them correctly can be a trick. You have to know what to set, and in what order, and what to call next.  It is far easier to copy a correctly-set-up object use than to make one from sc...

Basically, a bug is a combination of a design flaw and a testing gap. When I say design , I mean "design-as-written", not some keen plan that some keen mind build in some expensive drawing too. I mean the logic of the system. Built code can be said to have a design, in that it is intended to work in a particular way and has been adjusted to work in real circumstances. A non-coding architect's idea for a system is not a design. It is merely a guess, or perhaps a dream. If code has a perfect design for a given set of tradeoffs, then it will work perfectly for that given set of tradeoffs. If it must run on windows and use sql server, then it will work as well as possible under those conditions. It may fail because of supporting systems, or because IE/ISS ate all the cpu and ram, or because it is interrupted, or starved out by virus checkers, etc. For where it lives, and what it does, it will work great... provided the code is written to use the design. Side note: I...

This week I wrote a useful utility and taught some Python to a peer, attended a really great work session and a rough estimating session. I did some WIP management activities with my team, I broke the application, I worked with some awesome partners, went on a bit of a refactoring binge, devised (with partner) a grand strategy, and got stuck on tiny little problems I couldn't see over. This has been an awesome week. We have been doing some big refactorings, moving big and critical chunks from one module to another, and dealing with the fallout. I don't know how to tell you how important the tests in our code base have been. I would have spent all day lost without them. We would move a component, build, resolve build troubles, rinse and repeat. Finally, at end of day, I got all unit tests and fitnesse tests turning green, EXCEPT for a few that won't test because they do horrible things and need remediation. When our tests failed, it was not because the tests were bad (exc...

To make software, you need people who are skilled, creative, quick-learning, thoughtful, and engaged. You might be able to skimp on 'skilled' if the rest of your team provides a social learning system (via pair programming, test-driven development, book and link sharing, impromptu teaching, design talks, etc). You cannot really skimp on the characteristics of being creative, thoughtful, and engaged. If you tell someone that you don't care how they feel, they will work in an unfeeling way. If you tell them that you don't care what they think, they will work unthinkingly. If you tell them not to participate, they will disengage. This (IMHO) is why use of corporate software is so often without soul and without joy. If one self-important side tells the other to shut up, or to stop asking questions, or to leave the decision-making process, then he has switched off an important piece of capital equipment. If you treat a knowledge worker as a drudge, she will turn off h...

A friend of mine (Hi George D) suggested that this would make a good poster, but all I have is a couple of blogs, so here is the message that inspired my buddy. My experience is that the less well a team has done in the past, the more oversight is piled on, and that oversight reaches higher and higher levels. There really is no legitimate reason for the CEO to want to know which programmer 5 or more levels below was assigned to a particular task and if he's behind schedule by a week or so. In healthier organizations, the groups and managers that interface with the development group tend not to have the same meddlesome urges. In our transitions, the biggest problem we face tends to be peeling back the expensive and unnecessary oversight. If the team can be rebooted and work with a single stream of smaller, simpler stories (rest of agile practices included) then they can win over the rest of the org in relatively short order. Sometimes in only a year or two, som...