2005-07-27 16:20:40

Thoughts on development methodologies

 

Part 1: The silly and contrived introduction

I actually do like living here in the Midwest, so I suppose I should stop poking fun at Champaign.  But I just can't help it.

It's all Newsweek's fault.  Back in November 1998 they ran a feature story giving their list of the ten "Hottest Tech Cities".  Champaign was on the list, alongside places like Boston, Austin and Seattle.   It was nice to get the attention, but this story was ludicrous.  Any honest technology person in Champaign can tell you that in no way does our fine city deserve to be on a list with such elite company.

But that doesn't mean the recognition was completely without merit.  We've certainly got more interesting high-tech people and stuff here than any other farming community in the Midwest:

• The University of Illinois was the site of some of the very earliest work on computers.
• Folks at NCSA  created the Mosaic web browser and the web server which later became Apache.
• Wolfram Research, the producer of Mathematica, is the largest ISV in town.  Their product is so thoroughly dominant in its market segment that they can do almost everything wrong and still be hugely successful.
• Volition is one of the top game development companies in the world.
• Ralph Johnson is one of the "Gang of Four" authors of the classic book Design Patterns.
• Brian Marick is one of the leading authorities in the world on the topic of software testing.

This last bullet reminds me to check out Brian's blog and see what he's up to.  Aha!  He's actually not in Champaign at this moment, but rather, in Denver at Agile 2005 where he is one of the keynote speakers.

Which reminds me -- It's time for my annual peek into the world of development methodologies.

Part 2: Me and methodologies

I have never strictly followed any methodology, but I like to read about them, in part because I prefer not to criticize things of which I am ignorant, but also because I like to learn.  I'm leading a development team now, so it wouldn't kill me to expose my mind to some ideas from other people.  Besides, I already finished the latest Harry Potter book so I need something else to read.

Unfortunately, despite my natural interest in the topic of methodologies, I have a reputation around SourceGear as someone who hates process and structure:

• When we announced to the SourceGear team that I would be the project manager for Vault 4.0, I could swear I heard somebody snicker.  (All right -- 'fess up!  Who was it?)
• When Dan handed me the reins, he jokingly made a crack about me never having "successfully" managed a development team here at SourceGear.  (Ouch.  Thanks for the 'encouragement'.)
• While catching up with a former coworker yesterday, I mentioned that I was going to be the PM for Vault.  He laughed out loud and said, "Oh this should be good.  I can't wait to see if you can color inside the lines this time!"  (There are LINES ?!?)

Positive spin:  I prefer to think that I am simply more of a leader than a manager.  :-)

More seriously, I don't think my approach to development is all that terrible.  I'm not saying I'm the greatest project manager ever, but I actually do have a method to my madness.  People who use no process at all are accused of using the methodology called Code and Fix.  My approach just isn't that bad.

But when people ask me which methodology I use, I can't point to any one documented approach. 

Perhaps I should just create my own methodology?  All I need to do is write a good description of all the practices I tend to intuitively follow and give the result a catchy name like Scrum.  Then I can publish my book and recruit thousands of disciples to follow my particular doctrine of development.

But if I did this, I'm pretty sure I would end up creating yet another methodology which would fit squarely under the heading of Agile Software Development. 

Part 3: Agile Software Development

I wish that I too was at Agile 2005 this week.  The concept behind Agile Software Development is so very appealing.  It all started with a bunch of people who had each developed their own methodology.  Somehow they all realized that they had a lot in common, so they got together and identified their common ground.

#ifdef irrelevant_tangent

Why can't more people do this?  Like, for example, protestant churches?  Or even, dare I say it, the US Senate?  Good things happen when we focus on our common ground instead of on our differences.

#endif

This "common ground" called Agile is expressed in four basic values:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

These values make a heck of a lot of sense to me, except of course for that bit about tools not being very important.  As someone who works for a developer tools vendor, I believe that developer tools are the answer to all of the world's problems, and I don't want people believing otherwise.  ;-)

Anyway, I don't see myself adopting a whole new methodology right now, but I'm still enjoying some of the material I have been reading:

• I've re-subscribed to Roy Osherove's blog.  I used to read his stuff, but I think I stopped last time I changed aggregators.  Roy writes about Agile with a heavy dose of .NET mixed in.
• I found a blog written by somebody at an ISV in the Agile space.
• Martin Fowler has a great overview page.
• The Agile Alliance has some good high level material as well.

I've read some of this stuff before, but it's been a while.  Maybe I'll learn something.

Or maybe I'll find that one of the existing methodologies happens to exactly describe what I already do.  :-)

Part 4: The obligatory crabby remark

One thing is already clear:  I'm pretty sure the Rational Unified Process (RUP) is just not for me.  Every time I investigate methodologies I run across RUP.  This time I even bought a book about it, but the following snippet from the preface scared me away before I even got started:

"This book is not the complete Rational Unified Process.  Rather, it is a small subset to introduce the RUP."

This "introduction" is over 300 pages long!  Sorry, but I can't get myself interested in anything that heavy.  I see some excellent principles when I scan those pages, but I am inclined to think that any process that large is inherently not very agile.  Like I said, I don't like to criticize things I don't understand, but in this case I'll have to make an exception.  :-)