Why do I still see  many colleagues for every change in the code, redeploy and restart the application. Just to verify a code change. What a waste!

Every time you test your code using the GUI, a test is lost. And a lot of time is wasted. How much time does take to get you to the point that you can verify your code through the application? I guess 30 seconds to a few minutes is a fair estimate. Compare that with a proper unit test that run in tenth of a second. Every time. It was 2003 that Sue Spielman said her farewell to the debugger.

I say we should start by saying goodbye to our manual GUI testing, and at the same time say hello to short test-cycles too. If you start TDD or BDD, your time spent at the keyboard should be so much more interesting. To enter the same data in the GUI is only dull and repetitive. At worst, it is error prone. How fair is a test that is manual? Do you expect any other craftsman to do this? Would a carpenter test by putting everything together for each nail? Or would he test nail by nail and then module by module?

This leads to Iterative vs Incremental development. Let’s talk about that too.

My assumption was that a daily code kata would force me to learn different things every day. I got this tip from the founder of the pragmatic programmer, Dave Thomas. He suggested that a code kata is 1) an oasis where it is ok to relax without a deadline and thereby have the time to really learn something new and 2) learn how to play with code, reflect, refine and measure code.

My routine goes something like this, I start with an empty workspace and pick one of the many different suggested katas by Dave or by google and then just go with the flow. Sometimes I feel like using Regex (btw, have you read the joke about regex?)

Then, I just code until I feel happy. And I feel happy every day!

Try it you to, it helped me to get better insights in different java libraries, javascript, ruby, how to implement a simple test library, regex, maven, eclipse projects among all the little things. The beauty of it all is that I don’t store the code anyhow. I just throw it away when I don’t feel like having it around.

My hypothesis is that a daily rhythm make me remember to learn this every day. Love it.

Follow my daily code katas at twitter

Some people, when confronted with a problem, think
“I know, I’ll use regular expressions.”   Now they have two problems.

Jamie Zawinski (JWZ) http://regex.info/blog/2006-09-15/247#comment-3085

My responsibility at my current client is to be team leader for a development team of eight developers, two testers, two customer experts. My customer proxy asked me for a new feature. ”We have to have another type of user in the system” and the first thing I got was a rough sketch of what the user interface should look like.

I totally understand why he glossed over the reasons to actually do this piece of software change and new requirement. He had already spent hours and hours with a production problem. It was truly waste and should be eliminated. However, the UI sketch did not transfer this. His sketch was interesting but I didn’t get the why it was so important. For me, it transfer the understanding that this would take weeks to implement, would impact the security and permission aspect of the system. We have implemented two user roles with some pain. Another feature request like that was meant icebergs ahead. All manageable but feasible?

So, as this potentially was a mistake to implement without more thought, I asked him, “Could you please explain an example of what this will solve? Just to get my creativity going”. What I wanted to know was – what is the Goal or Desired effect. Was every option for a non-technical solution tried? What about the FAQ? What about the customer support first line? Let me see the knowledge base customer service use. Is it updated? Is the knowledge base used? What does the user FAQ look like? Can that be used? Enter the effect map

After some discussion we got a couple of examples

Example
“A user may enter foo and the system does blah, which is confusing. A system administrator can view the same foo as the user and support the user same view as the user” – that is the new feature. Most information that the user enters is private to the user and not even the system administrator is allowed to view it by default. Ten minutes of discussion in front of a white board with two pens helped here. We agreed on a couple of examples that are problematic for the user in the current in-production version.

An amazing thing happened here, I asked the customer proxy, “If we look at these examples on the white board, could we agree on a desired effect or goal for the new function?” Another five more minutes and we had one sentence that described the new function. “To be able to understand whether the user acted foolishly in the system or is it a missing function?” That one sentence was written using all kind of trivial words, yet it captured the essence of that new role of the user in the system. Someone that is able to get the same view of the system as the user.

So, I asked, who can fix this? Interestingly, the proxy assumed I was talking about “who” as in what part of the software. So, we used the white board and spelled out “Customer phone support” and “FAQ”, “Database administrator” and “third line support” and so on. Some very interesting details showed up here that were not technical, for example, the knowledge is maintained not by the support but by an email to an administrator of the knowledge.

I asked “Who is that administrator? Does she or he get tons of emails? ”
and the answer baffled me, “She resigned last week” – wow! We agreed that a replacement should be the first priority if that was the only way to update the knowledge base.

We tried a couple of other non-technical solutions and some possible solutions that wouldn’t require software to be developed. Five minutes of more discussion and more people got excited and interested around our white board. It was fruitful, as it was a potential solution and we could review this and be certain it was not an option.

So, this is all interesting, we got other part of the system documentation improved. However, have we addressed the issue and got to the desired goal? Can we decide if the user is behaving foolish or is something wrong? Not really, something is missing. So I said, “What if we ask the user to this and that, that we already have. (I’m not allowed to tell you what). We just leave this note in front of the user of specific things to do so we could help them. ” That turned everything upside down. Problem solved, just make a few tests that it does not interfere with existing processes and that the user documentation is updated with a note that “If you get stuck, please follow these simple steps, and we will get back to you”.

Some more discussion gave us that, if we just document this, problem solved! WHOA! That saved us so much trouble! I estimate that the initial sketch implementation by the customer proxy would take weeks or months to get right. Money that we saved by some spending half an hour in front of a white board. Simple questions.

Get me right here, I didn’t make this saving. I just happened to know how to ask the right questions. The real heroes here is the bright and talented people that really tried hard to find a proper solution to my probes. Was there any non-technical solution available? What is the goal or desired effect? I didn’t come up with that. I’m just a random guy who know how to ask questions. I let the customer to reason around these questions.

It is so often a developer team is asked to implement a feature that I made it into a pattern. By merely asking simple things like “Please, let me know why this is important” and then “Let me help you asses that every non-technical solution has been tried” really help. Sometimes you don’t get to do mundane stuff. Sometimes you really have to, but then, at least you have a crisp and clear understanding why.

This is of course in itself not new. This is a facet of what is called “Derive Scope from Goal” and came to me by the excellent Gojko Adzic. You should try it too. What I’m seeing though is that it is somewhat delicate to ask the right questions. For example, you may get in a us/them situation or that some domain specific words may get custom without a user to validate them. As always in a creative process, it is a minefield. Carefully questioning can be delicate. I’ll gladly help you or your client with that.

Send me an email – agile at gunnarahlberg.com – and let us see what can happen.

Isn’t estimation of software development just another waste?

My wife is perfect at estimation. She can estimate exactly what size of jug I should use to save anything. But that is for food. How do we estimate software costs?

Given a budget process for a project, a good estimate of how much cost the project is maybe a good thing. The estimate can provide the product owner in a valuable gauge in how much money do I put in to the project versus the risk versus the possible gains. But all those are highly volatile. The productivity of any group has so many different factors. Just to mention a few, the number of external dependencies, unforeseen technical problems, scope creep, illness, hardware failure.

An alternative would be, just define that this project is allowed to run for a fixed period with a fixed set of people and an infinite backlog of items to accomplish and with a rough estimate in small – medium – large. And then evaluate how many story points was achieved. Give a small item one, medium two and large items four points. Let the experiences from the first iteration become empirical data for the next iteration.

This alternative has lower risk as the possible expense is set in advance. Anything that is not delivered in that iteration can possibly be either left on a backlog. The estimates now disappears and any data can be gathered from empirical data.

Too sad that people miss out on this.

Leave a comment if you want a follow-up on more details!

As a teacher, Gojko is one of the few that understand the power of teaching. It is all to seldom that someone with great familiarity of the solutions they teach also understand and listens to any other and novel problems someone share. It is hard to to put your self in someone else’s shoes. But Gojko does this remarkably well.

The problems that Gojko solves among many is a) how to understand what the customer really need in contrast to what the customer says he needs and b) how to make that into solution that evolve in collaboration with the customer and any other stakeholder like the quality assurance (QA) department and developers.

Let me start with an example that we worked on. Say that a ticket vendor say “we want more customers use our mobile site.” During the seminar, Gojko gave us numerous exercises like this. What interests me wither this example is that it took the group together with Gojko under 30 minutes to identify that rather than focus on technical things and software, provide mobile customers with something like “joke of the day” would be the proper first step, easy and cheap. I see that as something that focus on point a above, understand the customer.

Gojko also gave numerous examples on how to mary that with any standard process like Agile and even waterfall. You can introduce his tools with any process. Software is not the point. Customer value is the point.

Read more about Gojko at twitter @gojkoadzic

Other who attended
http://morgsterious.wordpress.com/2011/04/07/sucker-punch-to-my-agile-ego/

http://natooktesting.wordpress.com/2011/04/07/specification-by-example-my-thoughts-collected-after-workshop-with-gojko-adzic/