Friday, August 20, 2004

Why I'm not agile this time

Advice is often given to take what works for you from a software development methodology and to discard what doesn't. In my opinion this advice is dangerous in respect to implementing agile methodologies. The temptation is simply too great to take the parts you like such as little or no design upfront and ignore the parts you may not like or find too difficult such as pair programming, test driven development, code inspections or continuous integration. These methodologies are not as yet understood well enough for the nonexperienced practitioner to be able to make value judgments on their component parts. If a team chooses to ignore certain practices of an agile methodology then I believe they should not claim to be following that methodology.

It's for this reason that I cannot claim to be following an agile methodology in the development of Sydney, despite announcing my agile leanings in my last post. To the best of my knowledge there are no agile methodologies that do not rely on a team of two or more developers. Whether it is pair programming in Extreme Programming, code inspections in Feature Driven Development or the daily team meetings in Scrum (ever heard of a one-man scrum pack?) a team of one simply does not provide the necessary checks and balances to be able to claim to be running an agile development project.

As long as I am running a one-man operation at best all I can claim is to be running an agile influenced, code and fix project. Either that or I bite the bullet and adopt a heavyweight methodology like RUP, and I'm far too lazy to do that. So at this stage my non agile development process will be strongly based upon Feature Driven Development and will also borrow several practices from Extreme Programming. I'll try to make it resemble these processes as much as possible in the hope that in the future should my operation grow beyond just me to be a team effort it will be easy to properly adopt an agile process.

I'll provide more details about my agile influenced, code and fix methodology soon. In particular I'll go into more detail about Feature Driven Development as it is not as well known as Extreme Programming.


At 11:44 PM, Blogger Rauno said...

Your links to www.Feature Driven Development are broken because they dropped the .com at the end. Thought you'd want to know. Feel free to delete this paragraph after/if you fix :)

Thanks for the rundown on development methodologies.

Do you think web services development needs these methodoligies? I can see that when you ship your code, it's pretty important to keep track of versions. To fix a bug, you have to ship another set of code. With web services, you can just keep fixing -- as long as you provide a time-date log for the fixes.

I've even noticed companies providing web services using this methodology to add functions.

If there is a web service methodology, I think it's in suggesting that on-going maintenance of code is, over the life-cycle of your service, much more important than all but critical initial bug fixes (yes, release with minor bugs). You use the power of networks to de-bug as well as suggesting functions.

Traditional publishing spends enormous sums to make sure not one word is misspelled while blogging focuses on the author looking over their work for glaring mistakes - good-willed users will correct the spelling and fix broken links. Is it the same to say that traditional programming spends enormous sums to make sure their software doesn't have one mistake while web services focuses on the service author making sure the service provides the function advertised, again, relying on good-willed users to correct glitches and suggest needed functions?

At 10:51 AM, Blogger Lachlan said...

Hello Rauno,

In short, yes I believe web projects should follow a methodology of some sort. Web development is no less susceptible to the same sorts of problems that development methodologies were created to address.

Thanks for the feedback, you've given me an idea for another post. I'll have a think about it some more for a few days and then maybe write some more on this topic.



Post a Comment

<< Home