Another Anti-Agile Gripe

As you may have already gathered, I have some reservations about the value of Agile and XP methodologies. I’ve even gone so far as to say that they are a license to cut corners.

I just read a very interesting post by Tony Wright, on the relative cost of fixing a bug in different stages of a project. Do we need a better justification for applying a little bit of forethought to a problem before rushing headlong into the implementation phase of a project? I guess the justification of an iterative development plan is that there is always a requirements, and design phase coming up that defects can be fixed in. The problem with that is that it blows out the project timeline, because time spent on developing worthwhile functionality is being spent on defect fixing. Not only that, the ‘agile’ ethos promotes a mentality that actively avoids solving problems ahead of time. That leads to short-termism that ultimately bakes bugs into the code!

About these ads

8 comments

  1. Hi Andrew,

    Actually I couldn’t disagree more strongly. With a good implementation of agile methodology you don’t actually write the bugs in advance, so there is nothing to solve ahead of time :)

  2. Do we need a better justification for applying a little bit of forethought to a problem before rushing headlong into the implementation phase of a project?
    Hmmm…I think I see where you’re going with this, but in my experience much more time has been spent on avoiding a problem than it would have taken to fix the problem, even in later stages of development. Obviously, I’m not saying throw the whole planning phase out the windows, but you can go to the extreme with preventive measures that leads to “analysis paralysis”.

    Personally I’m leery of the rules of thumb regarding the relative costs of changes in different development stages because I’ve found that most of those rules were developed in a time before the vastly improved development tools that we have today.

    Again, I’m not saying that we should ignore those rules and “rush headlong into the implementation phase”; just that tools like Visual Studio .NET changes the landscape so much that these rules become much less important. Yes, we still have to plan, but we can start prototyping/developing much sooner in the process than we used to.

  3. Hi Mitch,

    The problem with Agile is that it is adopted more often just to dignify a scramble to release than out of any ideological bias. Small companies use it because it allows them to focus on getting it out rather there than worrying about the quality of what they are doing. If they hit the bigtime THEN they can worry about quality. This seems to me to be fiddling while Rome burns. How many sites have you visited, got an error page and never gone back? How many were slow so you just gave up? How many had a great idea but never did anything with it (because that was too hard by that stage)? Quite a few I would imagine.

    I think that when I design a system I don’t expend that much more effort to produce a design that will stand the test of time. In Agile projects I’ve never had gottent to futureproof the system because the next release is just around the corner. The investors and/or projects managers believe that the current release will somehow make all the difference to the user experience/revenue/shareholder value – so we have to get it out and never mind about all that purist claptrap.

    My position is that it is not purist claptrap – it is best practice. With a slightly different and more formal dev team process you can produce good quality software for not much more cost. I don’t think that Agile is even bad per se! I think that it could be a component of a good programme management setup – I just resent the fact that it is embraced by people who never intended to do it the right way in the first place, it was just a flag of convenience.

    As for those metrics – everything is relative of course, and the figures will be different now that we have high quality tools. But lets face it, staff turnover means that we’re always coming onto code bases that we don’t fully understand and a bit more forethought might make that experience less uncomfortable.

    I’ve heard that ‘analysis paralisis’ excuse so many times it makes me want to scream. All of the failures I’ve ever seen (or taken part in) were due to a lack of forethought! Lack of requirements elicitation or rushed development leading to expensive reworks to overcome poor designs. I’ve never seen a project fail due to over design or excessive requirements management!

    I rest my case yer ‘onour!

  4. Oh, and another thing. I saw more projects fail due to economic downturns or reckless board level promises than due to agile practices, so I’m sure there will be more gripes in the future about non-agile projects!

  5. Andrew,

    I think your use of the word bug is completely wrong here. Agile and XP promote unit testing for every implemented feature, so for a start with the unit test passing, there is no bug. The feature was simply implemented based on current requirements, doing what it is supposed to do with minimal effort (not quality) of coding.

    All those methodologies promote is to not trying to predict the future and waste time on implementing things that might be useful in the future, well knowing that whatever was implemented for future use will not solve the unpredicted change in requirements.

Comments are closed.