Agile Perlcast

{

The latest Perlcast features Andy Hunt, one of the Pragmatic Programmers, talking about Agile Programming. Although my use of perl in a professional context is limited, Perlcast is one of my favorite developer podcasts in no small part to its host, Josh McAdams -

The following are discussed:

1. Pair programming
Andy gives an analogy of a driver and navigator. Interesting, but I have to admit the whole pair thing has never quite had appeal for me. At least, not as the "navigator."

2. Learning sessions
Andy recommends company learning sessions in the middle of the week (my own company does it on Friday). It's a good idea since the beginning of the week is catch up usually, and by the end a lot of people have checked out. I do like the fact that on Friday, however, there is a bit more of a relaxed atmosphere in the office, making the learning sessions double as a sort of group bonding where the developers can hang out and not feel too much stress.

3. On keeping up with what's current
Focus on awareness, not necessarily depth. It's impossible to know about absolutely everything going on, but keep your radar going and understand the big picture meaning of what's new. Easily said, but I will admit to frequent moments like today: feeling utterly overwhelmed by the amount of useful information that's out there. And no time to process the little I get a handle on from time to time.

4. Estimation
Andy's gotten companies to go with incremental estimates of time for projects. This is a great idea, but as Andy seemed to concede, it's sometimes hard to get a client to look at things that way. Because budgeting for a project is usually based on a proposal, and the proposal must take into account the entire scope of work, I wonder at a good angle from which to introduce this... maybe with shorter cycles up front. Unfortunately, the beginning of a project is usually a lot of design work and may not involve a ton of demonstrated progress. Hm...

5. Testing
Wow - this was the best part of the podcast. Andy goes through a bunch of acronyms to use to remember the different ways to approach unit testing. I'm not usually one for acronyms, but in this case I think it can't hurt. He recommends as much test code as production code... a really tough sell since I don't think any of the clients I've worked with run numbers on bug fixing costs. Because of that what's important to budget both time and financially is the "development" cycle and whatever is left over before the magic deadline must be applied to bugs.
But here's where I take it: the half/half production/test code thing is about the effort a developer makes to test and have automated unit tests available for their code. And, from a guy who's spent the last many days almost exclusively fixing bugs, I'd rather invest in test cases than bug fixes. I'll have to strategize on having lots of shiny things to throw at the client in order to demonstrate progress but somehow pace development so that much more is invested in unit testing.

6. SCRUM
Andy finishes with some talk about SCRUM as a lightweight development process. I'll have to read into that a bit; it seems to formalize some of the things that I've done in the past but it seems like a magical ideal that is very difficult to be disciplined with in real life. For example, quick meetings at the beginning of each day tend to expand in the amount of time they take. A lot of the time, if there's something that is really involved (like it's going to take a few days or weeks to develop) I prefer to just get to work and get into my code since mornings are one of the more productive times of day for me.
One thing we've done on my current project is have an email sent out that lists what everyone is working on, seems like a good compromise.

7. Write readable code
'nuff said.

8. Some OO design commentary, bleeds into contracts, encapsulation.

9. Architects should code.
I think Joel said it all when he wrote about Architecture Astronauts. Another funny article I recently refound online a humorous essay about UML Fever.

}