The pragmatic programmer recommends a tracer bullet or spike in this case. This means you implement some kind of prototype in order to clarify how to implement it properly.

And than you throw that away and implement it properly again, which for me means test driven.

Do you really do that? For me this goes against the principle of baby steps and of refactoring instead of rewriting code.

Also I was fearing it wouldn’t help much, because the problem wasn’t so much that I was unclear about the code, but about how to test it.

So last Friday I tried a different approach. I call it ‘Sketch and Test’

I started by implementing the complete thing in one single class. Without tests (scary, I know). But I never actually executed the code. I just wrote it as I thought it should work.

Once this sketch was finished I looked at the code and considered the changes I needed to make in order to test it.

I did the changes and finally created the tests, fixing the bugs I found in the progress.

Only when all the tests where in place and green I actually started the application and tested the new feature.

It worked, i.e. the feature did what I expected. The code qualifies as clean and I had complete code coverage with the only exception of some weird exception handling code, that I found hard to trigger in tests.

What do you think? Is this a viable approach? Or is it just a symptom of my limited TDD skills? Or both?

Glass with water

I found a new (at least for me) metaphor: people are like water. The cool thing about this metaphor is: When you manage people you can use it to learn from the engineers building channels and dams. So here are the things you can learn:

If you want to stop a certain behavior, build a dam not a wall. A wall, i.e. a single action won’t change the behavior very much. A hundred years ago dams where basically thick walls. In case of a flood, waves would crash against the wall and destroy it fairly fast. Nowadays dams have long slopes. Waves run up these slopes, loosing all their energy, without doing damage to the dam.

How does that relate to people? Ever tried to convince the employees of a company to do anything by writing a single e-mail to all@yourcompany.com? Had any success? Probably not. If you wan’t to change behavior, you have to work on that change everywhere and all the time. With small but constant force. You need trainings, presentations, reviews, e-mails and the communication at the water cooler, until it slowly sinks in that the change is not just the weird idea of a single person, but the new company policy.

If you build a channel water will run fast. Make sure this is really what you want. Rivers with a bed make a river easy to handle and predictable under normal conditions. But they are also considered cause of many floods, because the water of the river can’t escape the channel and rushes forward until it finds a weak spot.

Many process systems look very much like such a channel. They are build for everyday work, to make it as smooth and fast as possible. But what happens with your processes, when the environment changes? When you suddenly face twice as many customers? Or only half of the normal load? Or if a real big customer comes with very special wishes? Do all employees, when to look left and right of their daily routine, in order to find creative solutions to new problems? Do they understand why the processes are the way they are? They will need it in order to change their behavior without breaking the system.

If you keep water from going one way, it will find another way. I see this ignored very often when it comes to prioritizing tasks. Some people seem to have the illusion that the simple fact of attaching a high priority to a task will make it happen fast. This results in task lists, where almost everything is high priority. Obviously this means some things are set on a high priority that really don’t belong there. So, what would water do? Imagine a flooded area, where you want to protect certain buildings with dams. Of course you could build a high dam around every single building. This will cost a lot of money and effort. And it will also reduce the space where the water can go, thus the water will rise higher, eventually flooding all the high dams. If you instead build only high dams around the really, really important stuff, medium dams around the important stuff and small dams around the not so important stuff, stuff will get wet, but the really important stuff will stay dray for much longer.

A small rupture in a dam will get bigger … fast. This is really the old broken window thing. If things change in a way you don’t like, make this clear immediately. Otherwise after a short time, the new way will be the accepted way.

All the analogy considered the water (people) as an enemy, which is really a stupid thing to do. Water is tremendously important, so are people. If your let run water as it wish, it builds beautiful rivers, finding its way to the sea without any help. And if you really want to change its path without constant watching, monitoring and dam building, make the new path the easy one. Want your developers to properly use a version control system? Make sure it fits their needs. This means: It must be easy to obtain a repository for a new project. It must integrate with the IDE. It must be cool, at least to an extent that other people at a conference don’t laugh at you or worse pitty you when you mention it.  Do you want every issue to be tracked in a issue tracking system? Make it easier to use for them then the alternative (Excel, Notepad …). Sure all the 100 little details, that some systems can track might be interesting for management, but they won’t help you if the user only add issues when they absolutely have to.

The goal of the Agile Process Maturity Model (APMM) is to provide a framework which provides context for the plethora of agile methodologies and practices out there today.

First I was quite impressed by the BWPS ratio (Buzz Word Per Sentence). I count 6 (counting “Agile Process Maturity Model (APMM)” as one). But then I realized that this is what I would highly welcome: Context for Agile Methods. If this means we get an overview of all the process that you need if you do software development and then markers in this process landscape to indicate various Agile Methods to help with this process, that for sure would be helpful. But how would this be a ‘Maturity Model’?

So once again I had no choice but to read the complete article, including the comments. I must say, I was disappointed. What follows is basically a ranking of agile process, methodologies or what ever you want to call these. Such a ranking explains the ‘Maturity Model’ part, but it completely voids the agile part. What value can a ranking of processes have in a context where the common understanding is that processes aren’t that important anyway?

So my clear opinion is: No thanks we don’t need another maturity model, the existing once are causing enough problems. I know some of my coworkers are reading this blog and are by now probably thinking: “Interesting opinion for the quality manager of our company”. So let me explain why I think ISO 9001, SPICE, CMMI & Co are often doing more harm then good.

The problem is the same as with any kind of measurement: If you measure people or they work, they start to optimize for the measurement. For example if you start to measure code coverage and declare high coverage to be good, people will create automated tests for code that gets created automatically, although in most cases these kind of tests are of very limited use. With all the quality norms the auditors look for proofs that a certain aspect of a process gets executed as intended. This is really difficult to do, expect for the cases where documentation is created. But documentation created only for some audit is actually the exact kind of thing you don’t want to have. It costs money, gets outdated fast after the audit and has no benefit for your project, your company or the customer.

How to avoid this pitfall is a topic for a different post.

1. Gather information. Make sure you have reliable information about
   • Which application has a problem
   • What are the steps to reproduce the problem
   • The version of the application
   • Does it happen only to specific users, specific machines or to everyone everywhere
   • When did the problem start to happen

   The important part is the reliable part. Users are known to have a completely different perspective on applications. I had users swearing there was only one message box although there where two (they didn’t understand the content of the second, but it was the information needed by the developer). The last point is a difficult one. In many cases you will hear things like “Oh it just started today. Everything was fine the last two months” Just to find out, nobody had used that feature before. Probably the best source of information is a clean logging trail.

2. Give a first estimate. Yes, that early. Most of the reasonable users are pretty happy with something like: I give you an update in half an hour. They might not be just as happy with: “I think I can look into this next month” but if this is the case it is at least fair to let them know. If the problem is urgent and the resolution time is long a workaround might be needed. Check your estimate every now and then. If you realize that you can’t deliver on your estimate for whatever reason, let the user know.
3. Make sure the bug is a bug and not a butterfly. Although users sometimes have a different oppinion: Software can’t do what they wish. It can only do what they say. So many times the behavior now classified as a bug was considered a feature when it was specified. If this is the case let the user know, give him a reason why it is specified this way, and inform him about the chances to change it.
4. Reproduce the problem. If possible reproduce it on your machine.
5. Simplify and automate. Often the procedure to reproduce a problem is long, but often some steps aren’t necessary. By finding these step you’ll gather information about what influences the problem and what not. If possible you should automate the reproduction of the problem using a test case. With a serious bug you will execute the steps for reproducing the problem a lot. If this takes 2 minutes, spending 2 hours reproducing the problem with a testcase might easily payoff before the bug is fixed. But even if it doesn’t pay off immediatly you will have another test case in your Test Suite.
6. Now we finally start working on the buggy code. Find the place where the state of the application is not the way it is intended to be. Often this will be just before a NullPointerException is thrown, but it might be a line, where an event should get fired but doesn’t, or where the variable Pi is supposed to be equal to 4 but actually holds the value 2. Add debugging output to show the problem.
7. Find a place shortly before the point found in step 6 where everything is ok. Add debugging output to show the absence of the problem.
8. Find a place between the spots identified in step 6 and 7. Check if the problem is present at that spot. Document it with a debugging statement.
9. Repeat from beginning from step 6 until you find the actual faulty line in the application.
10. Fix it.
11. Test it (should be easy with the automated test from step 5).
12. Let the user know when she will receive the new version.

Every process should have a tayloring advice to accompany it. So here it comes: You may not short cut the fixing, testing and communication part with the customer. You may use some short cuts in steps 6 through 9. But be prepared to return to the clean process when the shortcut turns out to be a cul de sac.

You may use your debugger instead of debugging output, but in the complex cases debugging output is easier and faster to use, especially if you have an automated test.

There are special cases that need some consideration, but those have to wait for a future post: Finding suitable starting points in step  6 and 7; Debugging in a distributed environment; Debugging with 3rd party software; reading stack traces.

What process do you use when debugging? What is missing? Let me know.