This post originated from an RSS feed registered with .NET Buzz
by Peter van Ooijen.
Original Post: It's the man, not the methodology
Feed Title: Peter's Gekko
Feed URL: /error.htm?aspxerrorpath=/blogs/peter.van.ooijen/rss.aspx
Feed Description: My weblog cotains tips tricks and opinions on ASP.NET, tablet PC's and tech in general.
Lately there has been quite a lot of discussion on "Agile" versus "Waterfall" methodology. Taking some steps back I want to add my 2 eurocents.
What is methodology? To quote Wikipedia :Methodology is defined as (1) "a body of methods, rules, and postulates employed by a discipline", (2) "a particular procedure or set of procedures", or (3) "the analysis of the principles or procedures of inquiry in a particular field". A methodology describes is the way you are going to realize your software system: what are the parts, what tools will you use and in what order will you work.
The Waterfall methodology is a historical one. In the beginning days of computing computing resources were very scarce. Everything, including every line of code, was first simulated by hand. When I started in IT waterfall methodology was the thing you had to learn to join in any project. These days every developer has the resources to try and run countless variations in code and design on his own desktop. So the historical origin of waterfall no longer applies.
Waterfall has to be done right by the people upstream. When they fail it's up to you to either row upstream and return the mess they have created or find a way out of it yourself. In my remembrance are two projects. In both cases I was handed an impressive pile of paperwork. Impressive in size but not always in content. The detail in which even the most trivial things were described were enough to beat every grain of imagination out of the person who had to implement it. In both cases the worst was kept to the end: the designer had no time left to describe the system's final modules. In these some really complicated matters were handled which involved pretty complex business rules. One application was a savings system. How to search and edit the address of a participant had been described in detail, but there was not a single line how to consolidate the savings at the end of the year. The other system checked working hours against legislation. What the main menu of the application should look like was described three (!) times. But how to check working hours against the complex rules of the law was, due to to a lack of time (budget), open to my own interpretation of the text of the law.
In both projects an appeal was made to my ability to improvise. As I am no financial expert nor a lawyer I bypassed the designer and went straight to the end user themselves. We set up a trial and error schedule of regular meetings and frequent updates. Step by step we managed to realize usable systems.
For the savings system I worked with someone who had worked for the company all her life, liked her job and was very keen on learning. Despite the complex flow of money we got it up and running within time and budget. For the legislation system I worked with people who had been working for their employer too long, were looking forward to their retirement and did not want to learn anything new. I had to drag every rule out of them, try to translate their jargon into mine and double check over and over again they did not say "yes" just to make me stop asking. My patience had a hard time but eventually we completed the project. Mainly because we were allowed extra time and budget.
Both projects started as a traditional waterfall but in the completion we did a lot of things which would sound pretty "agile" these days. Agile is based on best practices learned in the past. But the main thing I learned was that it's not the methodology which determined the success but the people behind it. It's up to us developers to adapt to change, even having been beaten unconscious by dumb design. It's up to the end users to show real involvement with the project. When somebody does a bad job in "waterfall", the designer doing half work, it will not always show up immediately. When somebody does not participate well in "agile" your alarm bells will go of the first day.
In the core of agile development lies testing. To have good tests takes dedicated people as well. You may have a very good testing framework but when there is no-one around to tell whether the result of the test is a pass or failure that test is just as useless as the big paper pile of upfront design.
A lot of people don't really have a methodology. They do have a set of best practices and rule of thumb but nothing formalized. I'm one of them. This story is not intended as a "How I found agile" confession. Nothing wrong with a well designed set of specs. But lots and lots agile practices are based on hard learned experiences, also by me. The main thing is that whatever way you work, you have to do it good. You want to design every detail up-front ? Make it a good design. Which might be, due to a variety of reasons, difficult or even impossible. Agile appeals as a way out but it is no silver bullet either. It does take even more dedicated people, not just the developer but also the end users. To make it works takes human beings: it's the (wo-) man and not the methodology, technology, tool or whatever else
Previous Topic
