jeromemueller.ch » 2007

Archive for October, 2007

Why testers fear Agile Development

October 28, 2007, 1 Comments

Let’s assume (for the sake of this argument) that the programmers can build one small idea in the first week. Then a second small idea in the second week. They even have time enough to fix the few defects they introduced in the first week. Let’s say they can sustain that pace forever.

The program grows steadily. But what happens to testing?

Manually test each iteration

If we manually test each finished idea, the diagram above is what’s going to happen. That’s because we have to make sure all previously built ideas still work properly. Obviously it wouldn’t take long for testing to cost a lot more than programming. And it’s almost certain that at one point in the future, the testing will not be done, when new software is ready.

So that doesn’t work.

Manually test each release

Why not wait for a while, and then test a set of ideas together - so we only have to test them once. That’s what’s going to happen:

Because there is more and more software, tests will take longer and longer.

With all defects of 6 iterations found, the programmers won’t be able to work on a new small idea for a week. So the 12 ideas that could have been done in 12 weeks are now done in 13.

Progress is getting slower and slower. That’s not what Agile promises or is about.

No Manual Testing

That’s why automatic tests are crucial for Agile development. There is no way around it. If you want to make steady progress, you need automatic tests.

It’s the teams responsibility to make sure it has sufficient automatic tests. There is no test department doing that.

No testing phase = no testers?

If the testing phase doesn’t exist anymore, where are the testers? And that’s (one of the) reason(s) why I think a lot of testers don’t like Agile development.

I believe that testers will need a different skill set than now. They will have to work more closely with customers - helping them discover untested areas. Helping them break down big ideas into smaller ideas. Helping programmers figure out a way to test something automatically, that is particularly hard to test automatically.

But once they do all that - they aren’t testers anymore. They are team members. And that’s what they always should have been.

Funny definition of “iteration”

, No Comments

From one of the meetings I attended:”Iteration end is 7th of September or one week later - or two weeks later. Or three weeks later, depending on how many more weeks we need.”

Observations on why we get paid (’Why we get paid’-Series)

October 20, 2007, No Comments

Here are some observations on why we get paid.

From a Development Company’s perspective:

Making A smaller increases the number of projects that make economical sense
Making B bigger means giving the customer a competitive advantage
Making B bigger is what Software Development companies generally don’t care about
New technology has to either make A smaller or B bigger or both.

From a Customers perspecive:

Trying to make A smaller is what outsourcing is about
B is harder to quantify than A. And A is already very hard to quantify.
Customers don’t spend enough time quantifying B.
Optimizing A doesn’t make sense if you sacrifice B

Do you see any others? I’d love to hear them in the comments!

Big projects are just a bunch of little pieces

October 13, 2007, No Comments

Breaking down requirements

One of the most underrated skills in developing software is to break requirements down into smaller pieces. You can do that several ways. For example you can conclude that to be able to write the program, you need to have the database in place. So you start with database design. Then you go on to write the business logic on top of it. Finally you add the user interface. Let me call these pieces technical slices.Another way would be to slice by functionality. For example we start with the administration tool, so data can be added to the system. Then we write the functionality for the shop. Then for shipping the items. etc.Very often those slices appear to have dependencies on others. For example:

Can you write the business logic without the database?
To be able to sell items, there has to be a way to add items to the system

For agile development it’s crucial to be able to break down ideas into very small pieces of independent functionality. Why? Because you want to let the customer chose what is most valuable to him and work on that. If the pieces of functionality (called “user stories” in Extreme Programming), aren’t independent the customer has no choice.Little pieces of functionality means it can be implemented and ready to use in about 2 weeks or less. Finding those pieces is a new skill - it isn’t taught at schools.Breaking the requirements down into little pieces has a lot of advantages but also some disadvantages.

Advantages

Little pieces of functionality…

…are done quickly, giving the team a lot of small successes - increasing motivation

…minimize risk, because you can do the tough stuff first and find problems early

…help the project make money fast, because you can have a valuable subset of functionality ready for use early, decreasing your time to market

…enable changes in requirements, because things that aren’t implemented don’t have to be and new ideas can make it to production fast.

…increase visibility of the projects progress (e.g. Running Tested Features)

…help you recognize problems in performance, usability and even help you discover misunderstandings. Early, of course.

…are easier to test (because there is less to test) and easier to test automatically (because they are independent)

Disadvantages