Bloggings Been Light

Hi Gang (I know I've got at least 3-4 readers out there, hey, that puts me well above average)

Blogging has been light, because I've been seriously thinking about a post. Last week, a bunch of different blogs posted about working alone and Agile/XP/TDD. I found it interesting, because this is for all intents the situation I'm in (department has 15 programmers, but mostly, we work alone - dumb, but)

Agile/XP programming and the OODA loop

Today, over at Inc.Com, Joel Spolsky of Pragmatic Programmer had an article called Fire and Motion, where he talks about getting your competition responding to YOU. It's a really good post that I think you should read.

When I was reading it, I was reminded of

John Boyd's OODA Loop, and all of a sudden, I realized WHY Agile/XP works. It's NOT the Agile Manifesto. It's NOT Pair Programming, or any of the OTHER tools. Agile/XP is a Tool to speed up your development teams OODA loop massively. One of the tenants of the OODA loop is that a GOOD decision, quickly implemented, beats a PERFECT solution delivered later.

Let's think of what XP/Agile has you do - Short iterations. Observe at what the client needs, and quickly fill that need. Not necessarily with a perfect answer, but something. Then ask the client "OK, Now decide how it needs to change", and then add that. Quick loops

Why I never thought of Agile/XP in terms of OODA before, I don't know, but it was a light bulb going off

New Software - Get them while they're hot

Oooh - some new software for the development world:
NUint 2.4.2 - the defacto standard in .NET unit testing software
Code-Rush and Refactor! Pro

Barriers to Agile Development

I just ran across an interesting blog post RE the Barriers to Agile development at

barrier to agile development

Personally, I can see how Agile and TDD work. MY personal biggest barrier is that MOST of my development time these days is spent porting REAL legacy code - VB 6.0 stuff (some of which were ported to VB6 from VB3!)

I've read
Michael Feather's Working Effectively with Legacy Code and Joshua Kerievsky's Refactoring to Patterns.

The BIG problem is that there are very few tools to get VB6 fat client NON DLL applications under test before you try a port, and if you have seriously UGLY code (and some of this stuff belongs on the daily WTF) you are basically FORCED to do the port, do hundreds of minor repairs to try and get your code running, and THEN instrumenting your code. Distinctly NON optimal.