My very first blog entry

This is my very first blog entry, and I've been putting it off for way too long.

For the last three years, I've been thinking a lot about the way, we build and maintain software. By "we" I mean both the developers at the company I work for, but also in the software development community as a hole. I've been reading a lot of books, and I've attended quite a few conferences, seminars and lectures on software development, and I have finally reached the point, where I feel I'm ready to begin contributing to the subject myself. This blog (On the way to better software) is my first real attempt to give something back to the community, that has taught me so much over the years.

In this blog entry, I want to share my thoughts on the book, I am currently reading: "Working Effectively with Legacy Code" (WELC) by Michael Feathers (check out the link).

To add a little perspective on why this book caught my attention, I'll tell a little about the job, I've had since November 2004. I work at a consulting company / ISV in Denmark, and lately I've been assigned to a product team building one of our products. 

The product was originally built in PowerBuilder about 7 or 8 years ago, but was converted, line for line, to C# by an outsourcing partner 3 years ago. This means that the application architecture was not improved, and whatever oddities were in the original program, is still present today, only magnified by the brutal translation from PowerBuilder to C#.

I was assigned to this project because productivity on the team is going down, the number of hours per bug fix and per change/expansion is rising, and the morale among the developers is suffering. My task is to help turn this project around.

The first thing I did was to have a few hours of brainstorming with the developers on the team. I wanted them to tell me all the things about this project, that felt like a pain. This included build procedures, architecture issues, bug reporting procedures, change request processes, time tracking and much more. This brainstorming session resulted in a list of almost 30 issues, or impediments, that the developers felt were most painful.

The next step is to assign each issue with a severity level and an estimate. I want to indicate which issues are the most harmful ones. The estimates will be qualified guesses made be myself and a few of the most experienced developers on the developement team, and they will indicate which issues will be the quickest to fix. These two numbers together will (hopefully) indentify the "quick wins", which will be started up first.

To get back to WELC, I began reading the book a week ago, and immediately I sensed, that this book will change the way I think about legacy code, and how to handle legacy code. 

First of all, the author defines legacy code as code without tests. Think about this for a minute: You can be writing the cleanest code, using all the best practices of software architecture and of your current development platform. But if you're not writing the tests to verify and document your code, your code becomes legacy code immediately! This means that the next developer looking at your code, will have no way of knowing what your code is supposed to do, other than external documentation of course. The effect is, the next developer will never know if the code is behaving correct or not! This is of course very, very bad!

So we should all be doing TDD, or at least be disciplined enough to write the tests for our code, before we release it to the public.

The focus of WELC however, is not TDD or the likes, but more generally how to improve code quality, bug fix hours, change request hours and morale on legacy code projects. And the key is to add tests. Not tests to cover every line of legacy code, but enough tests to cover the code changes we want to make. In order to do this, code dependencies must be broken, some code will have to be refactored, and all new code must be covered by tests. WELC lists lots and lots of techniques to do this, and the author takes you through very clear examples on how to employ these techniques.

I have not finished reading WELC yet, and I can guarantee, that this will not be the last time I read it. This book will not only help you save sinking projects, but it will make you think about, how you architect your software on "greenfield" projects in the future. This is indeed a very valuable book, and you should read it today rather than tomorrow.

Mikkel Toudal Kristiansen

On the way to better software ...