Skip to main content

Why Agile Methods Reduce Cost

The greatest cost of software development is complexity:
  1. The problems we are trying to solve are complex. The customers often don't understand the requirements completely before the software development starts.
  2. The mapping between the requirements and the software is also complex, so that misunderstandings between the customers and the developers are the rule and not exceptions.
  3. The software itself is complex. It is hard for the developers to get an overview of what it does, and the consequences of modifying the software are hard to predict.
This complexity adds risk to software development projects, so it is actually uncommon for software projects to complete in time and on budget. Complexity also results in poor quality, since errors occur all the way in the development process; in the requirements, while mapping the requirements to the implementation, and in the implementation.

The risk and the low quality obviously increases the development cost. The cost is also increased by the the need for more developers and experts who know how to handle the complexity, and the need for substantial testing to find and fix errors.

So how can we deal with this complexity?

Requirements
We cannot reduce the complexity of the requirements, but I beleive a good domain model is important to understand complex requirements. Make the model concrete by using examples. Model the object instances for a use case instance, and go through the variations and changes that can happen with the customer.

Communication
The number one success factor in development projects is communication. We need to improve communication between customers and developers, and within the development team.

Agile methods does this through a number of key practices:
  • Iterative development gives rapid feedback on misunderstandings between customers and developers.
  • Ideally, a customer should be available to the developers all the time.
  • Daily stand-up meetings improve the communication within the team.
  • Pair programming.
Also, the domain model is very valuable as a means for communicating within the team.

Software Complexity
By complexity of software I mean how many thoughts the developer has to hold in his head at once. Early Java frameworks separated the code into lots of losely connected classes and XML files. The purpose was reuse and easy configuration, but it nevertheless made the program fragmented and hard to understand.

I personally hate it when I have to jump from a Java class to struts-config.xml to find the name of a form Java class. I just want to push F3. I find it ironic that software developers that are designing user interfaces for a living can come up with something as awkard as XML configuration files.

It is said that the human mind can hold between 5 and 9 pieces of information at once. If you need to hold the 1 action class, 1 form, 1 DAO, 1 JSP page, 2 XML files and 1 Javascript file, that doesn't leave much space for the feature you are trying to develop.

Luckily, this situation is beeing addressed by a new generation of programming languages and frameworks such as Ruby on Rails.

I beleive the cost of switching to a simpler framework will pay back several times by the improved speed that comes by being able to focus on what you are actually trying to do.

Comments

Anonymous said…
Nice, but if you are going to speak about agile and saving time/money you really need to talk about the TDD aspect as well.

There was no mention on how agile advocates some form of testing. Be it test first (true TDD) or test after.
Unknown said…
Absolutely! Now you've got me inspired for my next post!
Isaac Rodriguez said…
How did we go from Agile Methods Reducing Cost, to Ruby on Rails? I am sorry, but you lost me.
Unknown said…
Point taken. The headline wasn't accurate. I'm thinking about Ruby on Rails as an agile framework, but it's not a method.

Popular posts from this blog

The problem with use cases

The greatest benefit I get from use cases is that they focus on the user. Use cases help me to think about what the user wants to do instead of only focusing on implementation details. The biggest problem I have with use cases is that they are not structured. They are basically free text. For instance, if we have a use case Withdraw money from ATM, we may define that it has a precondition that Open account is performed, but we don't get any help from the method to see that. What happens if someone later changes the Open account use case or defines a Close account use case? How do we find which other uses cases that need to be modified? We can look through the old use case diagrams and find dependencies, but I can almost guarrantee that these dependencies have not been maintained after they were initially created. The solution to this is to connect the use cases to an object model. I don't mean a use-case realization with view and controller objects like ATM_Screen and ATM

The Pessimistic Programmer

I decided to change the title of this blog to "The Pessimistic Programmer". Why? Am I a depressed person that thinks nothing will work? No, I am an optimist in life. Something good is going to happen today :-) But in programming, something will surely go wrong. I don't actually view this as pessimism, but as realism. I want to be prepared for the worst that can possibly happen. Hope for the best, prepare for the worst. But my wife explained to me that pessimists always say that they are just being realistic. So, I might as well face it: I am a pessimist. I think a good programmer needs to be pessimistic; always thinking about what can go wrong and how to prevent it. I don't say that I am a good programmer myself. No, I make far too many mistakes for that. But I have learnt how to manage my mistakes with testing and double checking. Über-programmers can manage well without being pessimistic. They have total overview of the code and all consequences of changes. But I

Use examples to make your code easier to understand

Programmers are used to abstract thinking. To program is to generalize: A method is a general specification of what to do during execution. A class is a general specification of objects. A superclass is a generalization of several classes. Altough our minds are capable of abstract thinking, concrete thinking is much easier, and concrete examples are the foundation for abstractions. For instance, when we were children, our parents didn't try to teach us about cars by explaining to us cars are and what they can do. Instead, they just pointed at a car that was driving by and said ”Look, a car!” When they had done that a number of times, we knew what a car was. Another example is prejudice. We all have prejudices, because this is the way our minds work. If we have met a few people from Denmark in our lives, and those people were friendly, we ”know” that Danes are friendly. And this works even stronger for negative prejudices. My point is that we learn by examples. Einstein said t