Archive for the ‘Refactoring’ Category

The train station in my home town was finished in 1913.

A train station that is 100 years old that means that it’s no longer adapted to the current needs. Meaning, they have to replace the station. Yet a nice building of 100 years old, also means that the building itself is “protected”. (Meaning they can’t destoy the look and feel of certain parts. )
These two together give some interesting dynamics. The project to replace the trainstation is a very interesting project. In this blog post, I’m going to focus on the project management part. It’s interesting because the train station will not close down while they are re-building the station. Or should I say refactoring the trainstation?

Let me explain what they are doing. (If you understand dutch you might want to watch their introduction video)

The original building they will preserve. As the building is part of the unesco world heritage (or something similar)

Yet everything else, all the train tracks, all the platforms and the tunnel below, will be replaced.
Personally I don’t believe in recreating software. Every project I know that rewrote software from scratch, was a near disaster. I once helped to coach teams that would create a software platform, to replace a few websites. (This company had a website for every country they were active in.) The decision was taken a few years before I came to replace everything. They did not want to create a link between the old website and the new one. So replacing bit-by-bit would not be possible. They considered that linking the two security systems would be too expensive. Unfortunatly when they wanted to put the new website life, a lot was not ready. And to keep their deadline, they decided (as I had predicted, 2 years before) to still link the two security systems. Only now that was quickly done, and created it’s own kind of problems.


All this to say I prefer to replace software bit by bit. Sprint after sprint, or week after week. I was on a train ride with one of the managers of that same company and we passed this train station, and he proudly said; well agile can’t work for everything, they can’t use agile to re-build this trainstation. I told him that they were actually doing very agile stuff. They had killed platform 12 and kept the whole station running while doing that.

(Ok there was a shutdown for a day or so.)


The whole rebuilding of the station will take about 20 years. That can’t be agile.Or can it?  For me agile is about adapting to change. And interaction with your customers.

The replacement of the first platform (12) took much longer than expected. 22 months instead of 18 months.  The engineer who explained all this said: if we would have been able to stop the station it would  have been done earlier. Although I don’t know anything of building trainstations, I doubt that. Most projects take longer as expected. Especially when you are sticking to a plan that is not working. And this is where we come to the most interesting part. They did not stick to the original plan.


For platform 10 & 11, they decided to change the plan. And instead of starting to build the platform from -1 and build it up till +1. They decided to start at ground level (level 0)  and build down and up almost at the same time. That way, they can keep their deadline of 18 months for level +1 (where the platforms are.) I am not sure if this also means they will make the deadline for level -1. And that is not really important, the biggest value for the trainstation is level +1 and level 0. If I remember correct, the lower levels are shops and parking spaces.


It’s important to notice that the way the station will look like, won’t change. It’s the techniques that they use to get there. (and probably some of the supporting structures, will be different.)


Like any big building that is created, they have a team of architects that are working full time. On a day to day basis this team takes decision on the infrastructure (read architecture) of the building. They don’t stick to a hug premade plan. The adapt.
If this can be done for a trainstation in use, why would that be a problem for your software?


Last week we published version 43 of the book Who is agile, Volume 1 (Yes Volume 1 as we have decided to create also a volume 2)

With version 43, we added Peter Armstrong as 89 person to the book.  That is the last person we add to Volume 1.

From now on, we have a quality control phase. (Wow, how un-agile of us…) What would Lisa  or Elisabeth say of this? 😉 )

these are the different steps we have to do for each person in the book:

  1. Spelling and grammar
  2. Are the  links to person you mention that are  in the book, are these internal book links working?
  3. Are the books you mention in the book list?
  4. Are your links you provided in the contact list?
  5. Is your question in the question list?
  6. is there anything you are missing in the book?
  7. is your location on the map correct?
  8. Update: is your location mentioned at the bottom of your answers?
  9. Update: Does  your location (mentioned at the bottom of your answers) have a correct wikipedia links?
    (You might want to download the latest version of the book for 9 as we only added the links on 2012/10/30)
    As you can see, doing this for 89 people and +20 community events is a lot of work. That is why we are sending out mails to everyone in the book to help us.

    Will you help us too?
    If you send us info, please add the version of the book you  have been reviewing.





Related to “Just do it” is this theme. The title is a quote from Grace Murray Hopper one of the amazing IT women (I added a book about her in the booklist at the end.)

A special case of perfectionism is people waiting for permission . Complaining that their bosses take to long to take decisions, or that they are moron’s that don’t take the right decision. Complaining does not help your situation.
Agilists are professionals. Professionals take decisions for their work.

Most perfectionists look for some kind of recognition. For some of them that locks them from starting anything without permission.
In reality most chefs are very happy when people come with solutions instead of problems.
Even happier when they execute things and report on the progress.

Some managers have not enough experience with this kind of behavior. Maybe you are a manager and this idea makes you afraid. What will people think of me as a manager when my people take decisions?
Will they consider me as a good manager?
Hold this thought for a while.
Let’s first focus what this could mean for your time.
– A lot less boring meetings
– A lot more time to do all the things that you are supposed to do. And you know do in the evening.
– You will finally have time to help your boss be successful.

⇒ Imagine you can focus on helping and making your boss successful.

Now go back to that thought you had before.
How will she think of such a manager?
Right, she will want more managers like you!

Do you see a pattern?
A perfectionist boss, creates perfectionist teams.
This is called team==product.

Agile Techniques Supporting “Ask for forgiveness instead of asking for permission”:

  • Retrospectives
  • Self-Organization
  • Refactoring
  • Visual Management
  • Small Iterations
  • Continuous Integration
  • Unit Tests
  • TDD
  • BDD


Just as there was a risk with “yes we can”, long term vision might block people block from starting. I call this the perfectionist syndrome. People rather do nothing than doing something wrong.
Well, in reality never taking any decision is worse than taking a wrong decision sometime.
The cure for this syndrome is “Just Do IT” A lot of books about starting your own business (see the biography), tell you the same thing: better start.

Just start doing something,as whatever you do now, it will be wrong anyway!
Ok that might feel bad. Stick with me for a second. If you take for granted that you will be wrong whatever happens, you will feel better if actually, what you do is wrong. (In the sense that, you did expect it to go wrong anyway. )

And if, by fortune, you are right, it will be a bonus and you have all every reason to have started !

The benefit of starting before you think you know what to do, is that your customer will discover what he wants by you showing him what you’ve got. (And you will discover it at the same time.)
yes, just like you, I want my customer to know what she wants before I start. Unfortunatly customers never do. When I show her what I have done. She looks at it, sees something she does not like and then tells me what she needs. Then I make a new version and we start over. After a few versions, we together create something my customer really likes. (This is true even if I am the customer.)

A lot of agilists, react to BDUF, which is the best know part of perfectionism. That is the old model perfectionism, the “Active perfectionism”.
In agile teams I see the same idea popping up: “ I can’t start with a scrum-board as I don’t have the right material/software etc…
The right answer is “Yes you can. Just DO IT.”

Just look at your todo list, GTD cards, backlog, what is blocking you from starting? Really? Are you sure it’s not resistance?
In Do the Work, Steven Pressfield goes over the different reasons of resistance.  Are your blockers really blockers or only resistance?

Look at your list again. Forget what block you and just DO IT.


Agile Techniques that support Just Do it

  • Continuous Integration
  • Refactoring
  • Unit testing
  • Daily Standup’s


Games that teach “Just Do IT”:

Thanks to Jurgen & Oana for reviewing this post.

One way to gain trust in people, is to gradually give them more responsibility. By splitting work up in very small steps, that is possible. There are actually lots of reasons to work in babysets.

My friend Pascal says, if its hard to do, do more of it.
My partner says to our kids: chew smaller pieces (of meat).

In babysteps multiple dynamics come together:

  1. When the work is smaller, the problems are smaller.  Joshua Kierevsky launched the limited red society in 2010. He wants people to do TTD and refactoring in smaller steps. The idea behind it is to keep the time of a none working project as small as possible.  As part of his e-learning course, they offer a tool that graphically shows when people are in the red.
  2. One interesting observation they saw was that people that are less in the red, usually end up with nicer designs.
  3. People that achieve a series of small steps, gain more confidence than people that do everything in one step. When I try to achieve one big goal I encounter a lot of problems, I only have a feeling of achievement at the end. (While trying I actually am frustrated most of the time)
    When I do something with small steps, I achieve one goal after another. Like with tdd where I implement one test after another.
  4. At the end of the day I actually feel I have done something (implemented x tests).==>  I gain confidence.
  5. Its easier for other people to see what I am doing.
  6. With babystep not only is what I am doing visible. It also shows my real progress.
  7. Because all the sub-steps are visible, they can congratulate me on specific actions. When they are specific in their congratulations, I tend to believe them more thus trust them more.
  8. When the direction I am going is wrong, people have the option to give me feedback (not possible if they only see work when my work is done after a few days)
  9. Depending how the work is splitted, other people might have the options to help me. When I do everything in one large chunk that is never possible. This way people see me less as the hero, but the work gets done.
  10. Not only can they help me, it is also possible for people to take over when my priorities change. (Both  personal or company driven priorities)

Update: Or like Peter Sims from TC says Don’t bet big.


At ACCD10 one of the sessions was a Marshmellow Challenge. This TED talk shares some of the lessons learned about the nature of collaboration.

As an agile coach and Core Trainer, I’m not surprised that the best results are created by teams that are working in small iterations. (Not aiming for the single right plan.)

Also interesting is that CEO’s become a lot better when executive admins are added. (Because they have facilitation skills..) Interesting that is why facilitating skills are so important for Scrum masters.

Lately I’m talking a lot about refactoring.

When I do, I use a lot a metaphor I have learned from Vera Peeters and Pascal Van Cauwenberghe.

Refactoring is like cleaning a kitchen.

If you observe the kitchen of a restaurant, you will see that they are cleaning the kitchen all the time.

So cooking and cleaning at the same time. (In other words I see refactoring as part of doing development)

Nobody would accept a cook to enter the restaurant and say: today the steak is 20 euro’s more expensive as we have to clean the kitchen first.
(And I presume that is when most people talk about refactoring and want a lot of money/time for it. They talk about doing a big refactoring that is more a rebuilding the kitchen instead of cleaning.)

Neither would a cook accept that I go into his kitchen and say: I want my steak half the price, can’t you not clean the kitchen today?

In the software world we let people tell us, do it quick and dirty, you can clean up after, when we have the time.

They presume it goes faster to build dirty code. Does it go quicker to cook in a dirty restaurant?

The big question is of course what to do when the kitchen is in a big mess?
(or what do you do when the code is in a mess)

There I say – use the boyscout rule: leave the place nicer than what you found.
In other words, do a little bit of refactoring to clean the code up every time you add something.
As we don’t want things to break, for me this would be start by adding unit tests.

To do this, I don’t think a team needs the approval of a manager.

A good book that helps people to learn about these first steps is Working effectively with legacy code.  I recently started yet another book Reading club at a client with this book.
I’ll write more about this in a future post.

Update: Another good book is Refactoring to patterns

Second Update: Joshua created a google group around metaphors, I hope you join the discussions around metaphors.

Third Update: Joshua is also the inventor of the Limited Red Society