Skip to main content

Posts

Showing posts from 2008

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

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

Agile practices don't primarily solve problems

But they sure help detecting problems early. And that's extremely valuable. For instance, iterative development with deliveries early in the project will test the technical feasibility and the development speed. But perhaps most important, we will get feedback on the functionality from the clients, to verify if we have understood their problem correctly. Failing in any of these areas will lead to project failure. And it is better to discover this when 20% of the budget is used than when 90% of the budget is used. First, you reduce your losses. And even better, you have a fair chance of fixing the project and turning it into success. Many agile projects succeed not because they are more productive, but because they discover problems in early iteations and then reduce the requirements. Unit testing is another practice that makes you aware of problems early. This makes it cheaper to fix problems, but it also gives confidence, so you dear restructure code when necessary. Another agile

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

Example Driven Development and Unit testing

In a project I once worked, we were required by company standards to write formal test specifications for manual testing. It was a lot of overhead to write these Word documents and get them through the bureaucracy. Finally, we proposed to write the test specifications as comments inside functional unit tests. That way, we could maintain the test documents easily. We saved a lot of work, and the documents got higher quality because it was easier to update them. And it really helped us to write good unit tests that covered the functionality. In this post, I will take this approach one step further to show how unit tests and manual tests can be unified. In an earlier post Example driven development , I argued that a few simple examples can be used for requirements, manual testing and unit testing. I don't say that a few examples are sufficient as a requirements specification, but they may be in relatively simple projects. And it is far better than nothing. Examples help you to thi

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 java.io.FileNotFoundException

Example Driven Development

This article is the first in a series about Test Driven Development. A test is an example of what a program should do. Examples make the requirements concrete, so they become easier to understand. I will show how examples can be used for requirements, manual testing and unit testing. I am currently working on automatic order handling for a client. I will implement a servlet with the following tasks: 1. Decode input parameters from a web page. 2. Generate an encrypted license with some of those parameters. 3. Store the license in a database. I can model this database as I want. 4. Store customer data in another database. This database schema is "carved in stone". 5. Send the license as an email to the user. This is a small project, where I will implement, test and deploy the servlet myself. If it doesn't work, my client will lose customers, and I will be responsible. So how can I make sure this doesn't happen? I don't trust myself to make so good quality that there

Use cases and robustness analysis

Use cases or user stories? Use cases are bigger and require more work. User stories are quicker and easier, more agile . That may be ok if you have other agile practices in place. If you have a customer or functional expert available to the team at all times, user stories may work quite well. But if you don't, you may need something heavier, like use cases. It also depends on the complexity of the requirements. If the requirements are simple, use cases are not necessary. But for complex requirements, I think use cases are better suited than user stories. They help the customer to think through the requirements earlier, and they give the developers better understanding of what the system is supposed to do. But use cases are not agile! Yes, they may be. Agile doesn't mean lightweight, it means right weight. It means you adapt the process to the project. A large, complex project needs a heavier process than small and simple ones. RUP had an activity called robustness analysis to

Why Agile Methods Reduce Cost

The greatest cost of software development is complexity: The problems we are trying to solve are complex. The customers often don't understand the requirements completely before the software development starts. 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. 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 t