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?

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.

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.


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.
Lars 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.
Lars 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

Database dump with Java

I need to update a database that is created by PHP. The problem is that I am not a PHP coder, but a Java coder, and I need to use some other Java libraries to get the job done. So how can find out exactly which tables to update and how? It would take me weeks to search the PHP code, and I still wouldn't be sure if I got it right.

The first step is to install a clean application on my computer. There is no user data in the database, so if I perform commands like creating a user etc in the web application, I can look at what changed in the database. I'm sure that could be done in MySQL, but I'm not an expert on that either. When the only tool you have is a hammer, everything looks like a nail. So, I'll use Java for that to.

So, I wrote a small Java application that produces exactly the output that I need. It reads metadata from the database to find all tables and columns, lists that metadata and the content of all the rows.

Here it is:import;

The Future of Programming

The problem with abstractions Programmers are experts in abstract thinking. To program is to generalize: A method is a general specification of different execution paths. A class is a general specification of objects. A superclass is a generalization of several classes.

Although our minds are capable of abstract thinking, concrete thinking is more natural, and concrete examples are the foundation for abstractions. For instance, how do you teach children what a car is? You don't give a definition like: 'A car is a wheeled motor vehicle used for transporting passengers.' Instead, you point at a car and say: 'Look, a car!' After seeing a few cars, the child understands what a car is.

Notice what I just did! I started with a general principle and then gave an example. Which part of the paragraph above is easier to understand, the first sentence (general) or the rest (example)?

Einstein said that examples is not another way to teach, it is the only way to teach. It is…

World War 2, Rationalism and Agile Development

One of the central values of the Agile Manifesto is Responding to change over following a plan. This doesn't mean that it's not agile to make a plan. You should have a plan, but you should realize the limitations of the plan.

Are there any parallels to this in history?

The Soviet Union had 5-year plans. Stalin was quite succesful in industrializing the rural country in a short span of time. But his methods did not work well in the battlefield. In the 2nd world war, the Soviet suffered severe losses in the beginning.

You can plan how to build and manage a factory, because the complexity is limited. But a war is far more complex. You cannot predict what the enemy is going to do. This doesn't mean that you should go to war without a plan. Far from it, you should plan as much as possible, but be prepared to improvize when something unexpected happens. As Dwight D. Eisenhower, a successful American general in World War 2, said: "Plans are nothing; planning is everything."…