New site is up!

http://agileinoslo.com is the new site for my blog! Remember to change your bookmark and RSS reader!

All posts and comments are already moved to the new site.

Being a coach is more than listening and giving advice

Socrates is one of my heroes from the history of philosophy. The idea of asking questions instead of giving the answers or well meant advice, has always been an inspiration to me. It might be my curious nature and that I want to know more about people and their thoughts on the world. But I have found that asking questions works really well.

"To solve a problem, it would be broken down into a series of questions, the answers to which gradually distill the answer you seek." [Wikipedia: Socratic Method]

The importance of questions is often mentioned in popular coaching methods and it often has the purpose of understanding a challenge or problem that someone has. It often opens up the conversation and you become an active part in the conversation instead of only being passively listening. Although this is a good conversation it is often important to ask the questions in a way that it is not possible to answer them with a simple yes or no. In this way you do not close the conversation and the person you are asking will often need to think more and differently before answering. This pulls the person out of the blind alley they were in.

If I am the one being asked the questions I feel inspired by it. There is a person that is actually listening to what I say. That person challenge me to go even deeper in my thoughts on the subject by asking all these questions that I am not able to answer with a simple yes or no. I'm forced to think and someone told me once that thinking is important.

Next time you feel compelled to give advice, maybe you should ask a question instead.

Visibility is important for motivation

People always say that visibility is important, but often they fall short when asked to give examples.

I thought I'd give you an example that is fairly obvious and can easily be tested. That's if you have a newer kin of Nokia mobile phone..

http://sportstracker.nokia.com

The sportstracker gives you a few data about your training trips, but it also give you motivation trough it's functionality.

You can have your own training buddies connected and then you can actually see what your friends have done. The application is actually quite simple using your GPS on the mobile phone and registering speed and altitude in your workout (cycling/running/walking++).

More important is the web site that creates the link between your buddies and you. This creates a sense of competition between you and your friends. I find it inspiring to see that a friend of mine has done a 10km track in an hour last night. I suddenly find myself wanting to do some running.

Maybe this can inspire you to do some of the things you do at work visible to others as well. Maybe it creates a small sense of competition and fun. Maybe it motivates you and your co-workers?

It surely motivates me! Too bad you can't use the mobile phone when swimming..

Maintenance - Repay the debt

It's time to repay some of that technical debt you have accumulated. The project has been running for a few years and often the code gets smelly. The code smells of complexity and bugs.

What do you do to approach such a problem? You clean it up of course!

Now I will tell you how you can choose what areas in the code you want to clean. For this you need a couple of tools. First one to calculate complexity and then you need something that tells you about changes in your codebase.

I have used Complexian and StatSVN in this example, but you may find other tools that does the same job just as well.

I started with Complexian and found that a few classes had a complexity above 21, which I consider as high risk. Then I combined those data with what we can get from StatSVN and came up with more that suggested that we should focus on the classes that has high complexity and many revisions. This because I reckon that a class with high complexity that is changed a lot must mean trouble. There is a lot of different approaches you can use, but this one proved to be sufficiant in my case.

From Complexian
Register.java: Complexity is 38

From StatSVN
Register.java : Lines of code: 2273
Register.java : Revisions: 32 (4th place)


Here you can of course add all the static code analysis you want, but for me this is sufficient to tell that there is something wrong with this class. In this way it is also easy to persuade the project manager that this is a risk that needs to be taken care of.

Then I dive in to the class to find if's and else's that needs a refactoring.. At the same time I notice that the class is in the wrong package as well. My goal is to reduce the risk in this class. Never refactor without a goal. Refactoring makes no sense if you do not do it to achieve something better. If the class never gets changed and you have no bugs that you know of in there, leave it alone. It would probably not show up as a candidate either since there would not be many revisions of that file.

Write some tests for those methods that have high complexity is hard, but rewarding. In this way you deal with risk in a professional manner instead of just "feeling" where to do you cleaning.

Hope this gives someone inspiration and a way to start repaying that technical debt they have accumulated during the years.

The Importance of Removing Impediments

What is an impediment?

I do not actually know, because it is such a difficult word. But what I do know is that the time I have to wait for a build to finish is not productive for me. It even costs the customer money. This is for me an impediment.

If the time it takes to build the application is too long it starts imposing challenges on me. When it takes too long I do not want to build too often.. If i do not build too often, the tests is not run often and I will not commit code very often. This leads to finding bugs much later than I normally would have if I had ran the build more often. So I use more time fixing the bug because I have produced much more code since i made the bug somewhere in the huge codebase.

Did you get it? If not let's run som numbers on it instead. Lets say that it takes 8 minutes to build and that you use most of the resources on your computer while doing it. The best you do is drink a cup of coffee or read up on some documentation while you wait. Let's say you do the cup of coffee and wait for 8 minutes to see if the tests fail or pass. Its not only you in the project, but ten people that does the same thing. We all do it 2 times a day, because it takes so much time and we dont like coffee that much. We do it every day of course. So the numbers become:

8 minutes x 2 times x 10 people x 5 days = 800 minutes = 13.3 hours

Not only does it take you 16 minutes a day to build, but it takes the whole project 13.3 hours to build a week. Let us then say that you work 40 weeks a year and your project runs for 2 years.

13.3 hours x 80 weeks = 1064 hours

So during the lifespan of your project it has been used 1064 hours for running the build. What if those hours could have been used to implement more functionality because you have so much good code that your build did not take any noticable time at all. Imagine that the cost where 1000 NOK per hour that would amount to 1064000 NOK used on build/coffee during the project.

1064 hours x 1000 NOK = 1064000 NOK

That is not just an impediment to me, but to the customer. Build time matters! So remove those impediments while you still have time left to do so. If you are not busy building the application of course...

Smidig 2009: Påmeldingen er åpnet

Påmeldingen er åpnet for Smidig konferansen! Jeg tror årets konferanse kommer til å være like fantastisk lærerik som i fjor!

Smidig på twitter
http://smidig2009.no

Do the rights things at the right time

Yesterday I attended the oslo xp-meetup with an expectation of hearing some inspiring thoughts on software developing using xp and agile techniques. What I did get was a very good presentation of lean startups and how to do the things that matter the most at the right time (like in xp and lean).

It was Kent Beck who presented his new ideas on what he defined as "the flight of a startup". The analogy used the different phases an aeroplane is in before it's cruising at 30.000 feet.
1. taxi
2. takeoff
3. climb
4. cruise

Kent emphasized the need to be careful about spending cash (if it was limited) in the taxi and takeoff phase. The most important issue that I noticed from my perspective was during takeoff where you actually remove functionality thats not being used because you want to get better scalability. I'd call it reduce the risk of cluttering up your good ideas with the bad ones. But as Kent said, removing features are not easy and often we tend to let them stay in there. Another interesting statement from the re-inventor of TDD was that you should ALWAYS track usage in you applications.

I will start to do just that. I will start putting in functionality for tracking usage in my applications. This to be able to get actual feedback on what is being used in the application and what is just waste. Then we have an actual map of the used functionality and with this we can start doing some real work. Removing functionality thats not being used will be removing code that slow us down.

If he is doing this talk somewhere near you, take the trip and listen in on the ideas. It's good stuff.
Another very nice post on startups here