Moving

I have decided to consolidate my blogs into a single one at http://john-dunne.blogspot.com/

Quote of the Day

Watch where the footpaths go before you lay down the sidewalks.

Grooks

By way of Tim Berners-Lee, I found this wonderful collection of Grooks by Piet Hein. They have a wonderfully whimsical character, like this one:

BUDGETING: THE FIRST LAW 

If you want to know
where your money went,
you must spend it quickly
before it's spent. 

Great Quote

Darren Hobbs: Agile Answers

Developing incrementally does not (in my opinion) mean taking your brain out before starting.

What happens when you don't "get it"

PragDave

Without exception, these early attempts at imitation failed: the car companies replicated what they saw Toyota doing, but only on the surface. They didn't really understand what was behind these practices. It was like trying to become an artist by copying the angle and velocity of the brush held by a master.

You see this happen often with various "agile" practices, like test driven development, XP, or Scrum. If all of the participants don't grok the practice, then they blindly execute a series of steps, and say, "See. It didn't work!"

There are two possible resolutions to this problem.

You can tighten up the process. Unfortunately, if you didn't "get it" in the first place, you are likely to cause more harm than good. At its pathological extreme, your team works like the staff of a McDonald's, with each person following a carefully prescribed methodology. If you are building the software equivalent of a Big Mac, then this might be perfect for you.

You can invest in your people. The old saw about giving a man a fish versus teaching him to fish applies here. For even the most simple project, it is nearly impossible to prescribe everything. At some point, personal judgement has to kick in, therefore it makes sense to equip the team with the mental tools needed to make the right decisions.

I don't mean to "dis" process, but I think you reach a point of diminishing returns, with "process improvement" whereas "people improvement" will always pay off handsomely.

Design by Contract is trademarked!

I was reading this article called Contract Programming 101, when I ran into this little gem:

Note: the term Design By Contract was trademarked in 2003 by Dr. Meyer, so all the little free software pixies are dropping the term like a hot coal. The latest favoured term is Contract Programming, as suggested by Walter Bright in 2004 and used in the recent proposal by Thorsten Ottosen and Lawrence Crowl to the C++ standards body.

That is not cool!

Index Cards

Extreme Programming has this strong tradition of using index cards to track user stories, or to aid in design through the use of CRC cards.

Now, I have always had a strong preference for Excel spreadsheets.  You can print them, e-mail them, share them, and save them.

But there is something wonderful in the very nature of index cards.  Their very constraints create interesting feedback loops.  Think of all the objections that you might have against them:

Index cards are too easy to lose.

Yes – but why are you writing anything important on an index card in the first place?   At the end of the day, the only important work product is the code.  Requirements and any other models exist to facilitate conversations about the code.  If you have been writing tests along the way, when the coding is done, the requirements don’t need to exist anymore.  The requirements aren’t sacred.  The only thing that is sacred, the desires of your users, cannot be captured in any format, but must be discovered through a constant dialog.

Index cards are too bulky.

If you have more index cares than you can manage, then your user stories are either too fine grained or your scope is too ambitious.  Either way, the cards are telling you that you need to change.

This is a pet peeve of mine.  Quite often, when you are doing the wrong thing, it will be difficult.  The correct solution is not to make it easier to do the wrong thing, but to change what you were doing in the first place.  

Only one person can “own” an index card at a time.

So what?  Distributed ownership is the worst thing that can happen in project management.  If everyone owns a task, then no one is really responsible for carrying it out.  

Having said all that, I am still mulling over the use of index cards in my process, and have started collecting links about index cards in del.icio.us.