Re: Frequently Forgotten Fundamental Facts about Software Engineering
Posted: Nov 12, 2008 4:42 AM
> Stable requirements are always desirable using agile
> methods or not, agile just tries to find a way to minimize
> the cost to the project when they do change (as is often
> the case).
Cost is exactly my point. IMO, it is more cost-effective to iterate more on the requirements, if they are recognized as being unstable, than to start iterating directly on code. You may be able to tell the customer the project will surely be a failure because of unstable requirements before you even start coding, which saves the customer a lot of money.
IMO, Iterations on code make sense only for addressing two problems: requirements changes due to causes external to the system/business process you model (for instance, you initially devised your app to use a built-in directory because no external directory was available, and in a later iteration you add support for LDAP and scrap the internal directory, because a company-wide LDAP directory has come alive), and additional features. Both these situations have nothing to do with unstable/blurry requirements.
> An iterative method avoids 2 problems of the sequential
> 1. You discuss requirements forever in the abstract and
> nothing gets ever done. (Analysis paralysis)
As far as I can tell, analysis paralysis is usually a politics problem, which cannot be addressed in code. If there's the will and the willingness to cooperation between the essential stakeholders, you don't get analysis paralysis. Otherwise, agile development will not be able to solve the non-technical problems. Alternatively, analysis paralysis may be a sign that the service provider is not able to provide a solution, or that the porblem simply has no solution (for instance due to cost issues). It should be better to find out about this before you start coding, don't you think?
> 2. You set the requirements in stone after a certain
> amount of analysis. After the product is done according to
> those requirements the users tell you that they won't use
> it unless some core parts of the application change. The
> whole application depends on those parts so you have to
> rewrite everything instead of just those parts.
Every modern project management process includes a process/procedure for handling change requests. It doesn't matter if it's about construction, boat building, designing a car or creating a software app. Setting requirements in stone is something classical project management got over a long time ago.
On the other hand, agile development does not address the problem you describe. Thorough refactoring and proper design do, but these are not monopolized by agile methods, AFAIK.
> Comparing writing software with manufacturing cars is
> misleading also.
Of course it is. I compared designing a car with software development, not manufacturing it. (On a side note, both processes tend to be iterative, only car manufacturers do not do blueprints for the car before deciding what the blueprints have to contain, and try to minimize iterations - which is something agile methods tend to maximize, as far as my understanding goes.)
> Cars using the same basic concepts have
> been around for 120 years now. Everybody and his
> grandparents have seen one and knows what to expect.
> Custom software is created from scratch, and in some
> cases even the wheel gets reinvented.
Your comparison may have had some meaning maybe 20 years ago, but doesn't hold water anymore. Any person using a computer at work and at home, and maybe also using a smartphone or some other sort of gadget has similar experience with software as with cars, I think. At least in the category of personnel I'm are interested in - people involved in consuming software services.
> Creating custom software is
> more like doing the haircut for a lady than mass producing
> a glorified cart.
Talk to a hairdresser. He'll tell you that most haircuts are routine to him. On the other hand, One haircut usually takes less than half an hour, while a simple class, not to talk about a small application, takes significantly more (unless it's of the hello world family). A class is often routine. Only, the big picture, putting all classes together isn't. Whereas there are few hairdressers put in a situation to orchestrate the proper match of tens, hundreds or even thousands of classes. So i'd choose another comparison, for instance between an architect designing a garden and a web designer, or between a civil engineer designing a bridge and a software engineer.
To summarize: I don't advocate against iterations, thorough refactoring, continuous integration, peer review, or other techniques that agile methods promote. Only, my understanding of agile methods (which may be wrong) is that agile methods promote quickly rushing to code. Which IMO isn't always the smartest thing to do. Rushing to code potentially increases the number of iterations unnecessarily, and thus increases costs and duration.