Agile Fluency

Over the years our team has been working according to Agile pratices and we’ve slowly grown into them. The process took alot of effort on our part, to keep pushing us forward and keep learning from our mistakes. Having made these mistakes, we where more keen on implementing the practices and we can still reference back to them now when something starts to slide the wrong way.

An interesting article was published on Martin Fowlers site called Your Path through Agile Fluency. It hits quite a key point in the fact that Agile (and Scrum, XP, …) practices are easy to teach and understand in a classroom, but difficult to implement in real projects. They don’t provide a ‘silver bullet’ methodology which changes efficiency from one day to the next. Teams take years to progress trough the Agile Fluency path, and most of them never get beyond level 1.

In our team, I think we now have a solid base in level 1 and our slowly working our way to level 2. Will we ever get to 3, or even 4? Is it even necessary for our team?  Time will tell…

Are you working on an Agile team too? Have the same experience? What level do you think your team is on?

Advertisements

Refactoring keeps it tidy

This is a translation of the dutch post I did for my company’s blog.

Refactoring coverRecently a friend of mine handed me a copy of Martin Fowlers Refactoring: Improving the Design of Existing Code (that’s what friends are for). The book is considered a standard on refactoring en can still be seen as a must-read for every programmer, although it published in 1999.

Refactoring means to rewrite code, in small, safe (backed by unittests) steps. Doing this cautiously ensures that there is no loss of functionality and results in a decrease of error-proneness of the code and an increase in readability and maintainability. As Folwer mentions: the compiler reads your code once, while your and your colleagues will be gazing over it and changing it a lot times during coding. Making sure your code is readable (really readable, like a book) will save you and your coworkers a lot of time!

Fowlers book also helps you maintain the DRY (Don’t Repeat Yourself) principle. If you have to duplicate a piece of business logic in your code, it WILL cause you trouble. When the logic has to be altered, you can be sure that one of these places will be forgotten.

Before Fowler starts working on a piece of code, to fix a bug or add new functionality, he’ll often start with a refactoring to better understand the code. This may sound strange, but it is almost impossible to write perfect code from the start. I don’t mean working code, but code that is open enough to support all the possible questions, extensions or other changes and still is small enough to only do what it needs to do. If you accept the fact that you are going to have to refactor, and that it’s not a failure for you as a programmer, you can write better, cleaner code.

My favorite tool to do this (in .Net) is the fantastic ReSharper. A lot of the refactorings in the book can be done automatically and safely with this tool. It has an enormous list of functionalities, and I’m still discovering new uses every day.

An important note on refactoring is knowing when to stop. Knowing when to start is one thing, but at least as importing is knowing when you’ve refactored enough, or when a refactoring isn’t going as planned and the best thing to do is undo your changes. Huge reworks are done one refactoring at a time. You can always come back tomorrow to do the rest of them. As long as you leave the code in a better state than it was before, your good!

Refactoring fits perfectly in the iterative Agile process and is a corner-stone of Extreme Programming (XP). It’s no coincidence that Martin Fowlers can be found underneath the Agile Manifesto. Clean code will also provide value for the customer. Although it sounds counter intuitive, investing time in refactoring saves time writing code. A win-win!

If you haven’t, read the book and start refactoring.

You’ll love it, it’s a way of life.

SOLID: what every programmer should know (according to my wife)

A while back I gave a presentation to my coworkers about the SOLID principles. In my slides I used the great motivational posters from Derick Bailey. The day before the presentation I told my wife what the talk was going to be about.

Not expecting her to ask any further (my wife is, rightfully so, not interested in the stuff we programmers get exited about, meaning, she is quite a normal person) I noted there where some funny posters in my slides.

She was interested!

She asked me to describe them, so I explained her the pictures and the principles, as simple as I could, which was really easy with the posters.

After I was finished she tilted her head slightly and looked at me. “And you have to explain this to other programmers? Isn’t this what everyone should be doing already?”

She made the best point anyone could make on the SOLID principles. I also believe this is the stuff every programmer should know and should strive to attain in his/her code (side note: they are not rules! They are guidelines and should be used as such.)

A great place to start sharpening your understanding of the principles is the very place (person) they originated from: Uncle Bob.