In early July this summer me and my family visited BELLE Epoque in Malmö. I asked the staff for a good apéritif to start the meal (which was nice). They served me a variation on a cocktail they had picked up at the bar Tjoget, in Stockholm. The cocktail is called Milano and here is BELLE Epoque's recipe:

5cl Aperol
3cl Blood Grape
1.5cl Coffee syrup (this coffee syrup is made with one part strong coffee and one part sugar)
Top up with tonic - make sure to make it a good tonic.

Mix all ingredients but the tonic in an ice filled wine glass. Top up with tonic. Garnish with blood grape peal.

I found this cocktail very refreshing. The balance between sweet, juicy blood grape and coffee is really nice.

The Milano
The Milano cocktail, at my bar in the kitchen

There was a conversation around software quality over at the Software Craftsmanship slack team. It's an interesting subject but it often becomes confusing. Some of the questions that comes up are: What is software quality and how can we measure it? I'll try to add my twopence to the topic here, and perhaps make it slightly less confusing.

Lets start with a definition and then go from there. Oxfords English Dictionary has this to say on the subject:

The standard of something as measured against other things of a similar kind; the degree of excellence of something

To make sense of that definition we need to understand the context. What "something" is and what "other things of a similar kind" is.  To me this is pretty simple. The only person that can define what "something" is are the users of the software. In an enterprise system this is the enterprise user. In a API library it's the programmer using it. In the case of an end user application, such as a word processor or a game, it's the end user. And they will naturally measure this against other similar products or against their perception of how other similar things should work.

So my definition of software quality is:

The standard of said software as the end user of this software perceives it, measured against other similar software or the end users perception of how other similar software should work.

This makes my measure of quality rather narrow. I'm actually only interested in how my software is perceived by the users. This is also how I receive the measuring points needed to define what quality in my solution is. Therefor such tools as code analysers and test coverage is only important as long as the feedback from them helps me guarantee that the end user receives high quality.

So now what we are left with is understanding what the end user values as quality. As we start out, trying a new idea on the market, quality for the user may well be speed. It's certainly what we need to know if we should continue. To achieve this we create a PoC (Prof of Concept). This is often not a very well designed piece of software. It may well be something we will throw away a week after release. It's is as little as is possible to receive the feedback we need. If the users likes to use it we know it provided them with quality. Now we need to sustain and improve this quality.

As we continue to stabilise and improve our product we need to ensure that the user does not experience a regression in quality. Then they may well leave us for a competitor. To achieve this we need to ensure we have well tested and well crafted code. Here all the tools we can use to detect if our code is up to the high standard we need are of great help. Tools such as static code analysers, test coverage and so forth. Practices such as code reviews and pairing. The definition of quality is till the same however. Only the measures differs.

With this kind of definition I think it's easier to justify and measure what quality is. Keeping it this way makes it easier for all involved to relate to quality. And quality often comes up in conversations when we talk about the software we work with. Most commonly people try to refer to code quality and has a perception that well crafted clean code is what we always must strive for to achieve software quality. Clean code is important in many contexts. But not always. Sometimes speed is what we need. Short term speed and throw away code. It is, as always a matter of trade offs.


During quire a few assignments I've been struck by the fact that estimation seems to be done purely out of habit. No-one seems to know what value it brings or if the data collected is ever used. So I've started to question the value of estimation and the way we do it.

This is not to say that estimation is bad and we shouldn't do it. I'm only asking the question of weather the estimation done in many places serves a value and what value is that. I would like to write something about this, based on my observations. However my observations are, by nature, quite limited. I would therefore love to get your feedback on how you do estimation. I would basically like to see if my theories are supported.

I will publish the results and my thoughts and assumptions during the fall. If there is material for it I will also do a talk on the subject.

Please help me out by taking part in this short survey.

Thank You!

Legacy code is something we all have to deal with at one point or another. It's all around us. Even if we find it scary we have to learn how to handle it without being petrified in the process. This article will look at some techniques that I have used to tackle legacy code. It's a collection of things that have helped me go from feeling scared and apprehensive when working in legacy code to feeling challenged.

Before we dive in I'll start with defining what legacy code is. I've done so before on this blog. Since then I've learnt a much simpler and more precise way to describe it. Legacy code is all production code which makes you scared when you have to change it.

But what is production code? Production code is any code that provides the business with value. This includes, but is not limited to, code that executes in production, test code, automation code and any other code that helps the business do it's business.

So here we are then, with the legacy code. How can we go about doing this scary job without causing to much pain to the customer, who probably doesn't want to be disturbed at all? What should we think about? What patterns and tools would be helpful?

When the customer asks us to work on a legacy system we need to ask them why. Why does the customer want us to muck around in this old thing in the first place? What is the expected value of the change? Is it possible to deliver this value to the customer? Can we deliver this value in a better way? Can we get an of the shelf product and replace the legacy system with? Should we make a system rewrite instead? (this one should be approached with utter care)

The answers to these questions will not just question the need for change. It will also help guide you in your work. It will give you the indications you need to know how ambitious you should be. When you start on the path of reworking an application through slow, steady improvements rather then a big rewrite you will find that ambition level is important. It is what will guide you when you decide how much effort you should spend on improvements. What is the expected lifetime of the system you are working on?

Once you have the answers it's time to figure out where to start. The most obvious place to start is of cause where you stand. This is usually an approach that works when you know pretty well what needs to be done and where. If you are about to add a feature to an already existing part of a system or fix a well known issue then you should start where you stand.

When you are not quite sure where the problem is or when you need to find out where the real problem hot spots in your system are there is another tool that can be really useful. It is called Offender Profiling. The technique was create by Adam Tornhill and is presented in his book "Your code as a crime scene". He also has several talks (for example here and here) on the subject. Adam combines many years experience as a programmer with theories from forensic psychology. This have allowed him to think outside the box and be able to find patterns hidden in our version control system's (VCS) history data.

By using the history data from your VCS, combined with some very simple complexity metrics, this will allow you to find the most likely candidates for issues in your code base. The inspiration comes from a forensic technique called offender profiling.

Adam has in his book combined various other psychology concepts with VCS data which will help organisations make better use of their software. But that is for another time.

Now that we know where to start we have to understand what the code does. This is usually the biggest reason for fear in legacy code. That we don't quite understand how the code works. What does the requirements for this code look like. How do I know I haven't broken anything when I think I'm done? There are several different ways to attack this. We will look at four different patterns, starting with test.

First out is a way to mine requirements from executing code using tests. The tests are called Specification tests.They are pretty much the same thing as the tests we create when working with Behaviour Driven Development. What we aim to do is to understand how the system we are about to change should work by writing black box tests. To do so we use Gherkin's Given When Then syntax. We then run the tests on a running system. This whole process should ideally be fully automated and executable from the command line. But if that's not possible, just manually be able to run repeatable regression tests is a huge benefit. There are a couple of different frameworks to help with this. For Java and Ruby there is Cucumber, for .Net SpecFlow, JavaScript has Karma. There are many other frameworks available as well and for most other languages. You can also use tools like Selenium to execute your specification directly on the UI. Even if you are executing your tests directly against the graphical user interface and the cost of maintenance seems high this is a good investment. If this is an old application the UI will likely not change much. Also, you will get automated feedback on stuff the user will notice. If you can, sit down with users and watch how they use the UI. Then write the tests based on your observation.

With some test in place to make sure we don't have regression from the clients perspective it's time to start understanding the architecture and the code. We will look at two of Michael M. Feather's patterns from his book "Working effectively with legacy code" (WELC). We will also look at how we can use Simon Brown's C4 model for architecture to understand the architecture of an existing system.

The first of Michael Feathers patterns is Conversational Scrutiny (WELC p. 224). When you sit with an extra hairy bit of code like a long method or complex class, you often talk with one or more colleagues to get some help understanding it. The conversation that ensues is well worth paying attention to. It will often contain the abstractions that are missing from the code. The abstractions and the words that would have made the code easier to understand. The conversation in it self is of cause the key to understanding what the code does. But also make sure to listen carefully for the hidden abstractions required to make improvements. They tend to be embedded in the reoccurring words used during the conversation.

What is also important to remember is that a mess often asks for more messiness. Even a good team of developers have a scary tendency to keep adding messy code to messy sections of the code base. When scrutinising the conversation and noting the missing abstractions, don't forget to add them in the code. Don't forget to continuously improve the code.

The second of the patterns from Michael Feathers is Telling the Story of the System (WELC p. 216). This is a technique used to understand how submodules and modules work together. Each participant is responsible for telling the others the story of e's module. The story should be as brief as possible, preferably just a few words. It should also be told as if the audience knows nothing of the system.

By doing the exercise we become aware of what responsibility belongs where, as well as where it is currently located. It is a great way to understand how the system should be re-structured as well as how it currently hangs together.

Simon Brown, author of Software Architecture for Developers, have described a way to explain software architectures he calls the C4 model. This is a very powerful way to illustrate what a system architecture looks like. Used correctly on a legacy system it's almost embarrassing how bad most architectures are designed. The tldr; of it is that you have four types of diagrams. Each describes a model of the system. At the top level we have a Context diagram. This describes how the system fits into the rest of the world. One level down we have a Container diagram. This will show which "containers" the system is made up of. A containers is a deployable unit. This can be an IIS or JEE server, a database, a Docker Container or something else that is deployable. At the third level down we have the Component diagrams. They will describe the different components in some detail and how they interact with other components. At the bottom is the Class diagram. Class diagrams are sometimes very illustrative but often to detailed and can be left out.

The audience for C4 is mainly developers. The diagrams are there to help understand how the high level architecture is structured. When the model is true to the actual system it is also a very good place to start when looking to change the current architecture into something more fitting.

Now that we have, hopefully, understood how the system works, it's time to look at some patterns for how to make changes without fear. Or at least as fearless as we can be.

Let's start with a pattern from Martin Fowler's bliki called Preparatory Refactoring. This is a practice we should be doing all the time. Actually, the failure to do so is the main reason to why we have problematic legacy code in the first place. The basic idea is pretty simple. You have a new feature which does not fit into the code where it's supposed to. To make sure you don't create a mess when plugging it in you first refactor the existing code. You are done with the refactoring when the new feature fits in as if it had always been there. The effects is that the code is cleaner and more suitably structured to the requirements it is there to serve now.

When doing this in a legacy code base you end up adding loads of test. Remember, you can't do refactoring without covering tests, then it's not refactoring. Dan North and Michael Feathers came up with a name of this practice of adding tests to a legacy system in order to be able to change a part of it. They called it Light the Forest.

Imagine you have been asked to chop down a tree in the depths of a large dark forest. You have problems seeing your hand in front of you. The sensible thing to do is to light your way in, cutting a path and mounting torches, so that you can find your way back again.

When diving in to the depths of a legacy code base you are well advised to do the same. Lighting your way with tests. We call these tests assumption tests. They prove that assumptions we make on our journey are correct and stay correct.

As you work with your legacy code base and apply Light the forest over and over again you will start to see patterns in the forest. It's like seams starts to appear in the system. Along these seams you can start splitting the system up into components which are possible to test individually. Michael Feathers calls this the Seams Model. His definition of a seam is:

“A seam is a place where you can alter behaviour in your program without editing in that place.” (WELC p. 31)

The seams are places where you can inject tests, mocks, stubs and other things. It is also places where you can start breaking up the system into smaller more understandable pieces.

To break the system apart at the seams we use what is called Dependency Breaking Techniques. Michael Feather describes several in his book (WELC). Dependency breaking is often common refactorings made more difficult by the legacy code base. In statically typed languages such as Java and C# mocking frameworks can help allot when introducing tests and breaking dependencies. I don't generally use mocking frameworks when creating new code. But in legacy systems they can be a real life saver.

Another way to understand what happens when you want to break out a certain dependency is to pass in a null reference. The test harness will then quickly tell you if the specific parameter is used by throwing null pointers when the code under test tries to use the dependency.

If mocking or passing nulls doesn't work a possible way is subclassing. By subclassing a dependency, or some times even the SUT (System Under Test), you can stub away especially troublesome parts whilst using the real code in others. You can either create a specific test double or let the test class extend the dependency directly. This technique allows you to understand the SUT in a very intimate way. It will usually also make the code uglier. This is OK as long as it is done in a controlled manner and is removed as soon as possible.

Another thing that tends to be lacking in legacy systems is good names. Helpful names, providing good abstraction, is what make code changeable, flexible and ultimately non-legacy. It is one of the key aspects of a good code base. So when you work in a legacy system it is important to continuously find and add the missing names and abstractions to the code. As we know naming can be very hard. The conversational patterns presented earlier can be of great help in this work, as is the conversation that happens when pair programming.

Something Kent Beck said a couple of years back that helps allot when it come to names as well is: If you can't come up with a good name, then come up with a really bad one. A good name will come to you at some point in the future and the really bad name will poke you in the eye so you remember to replace it.

What good names tends to do in the long run is to help create good abstractions. This can be such a simple thing as extracting a class for an ID. If the ID is just a string or number it's hard to find where it's used. When extracted to a value object you are bound to find places where certain simple operations are preformed on the ID. Such as an equals operation. In some places there will be a null check, in others not. A common problem for bugs and a headache when changes are to be made. If ID instead becomes a class all this functionality finds a home. And all of a sudden ID's are not longer some random string in the system. It's a thing that we can reason about, not just on the whiteboard but also in code.

When you have found the names, and the classes or functions you want to create, you can use a number of common refactorings to extract them. Some are: Compose Method, Method as a Comment, Extract Method and Extract Class.

This article only scratches the surface of the subject legacy code. But I do hope it has tickled your curiosity enough to continue explore. A good place to start is the literature I've mentioned. Especially Michael Feathers and Adam Tornhill.

I would love to get your feedback, thoughts and ideas on the article and the subject in general. Did I miss something? Is there something that's not correct? Do you disagree? Or do you have furthers insights, thought and ideas you'd like to share? Please do post a comment.

The article is derived from a talk I do about tackling legacy code. If you are interested in this you are welcome to get in touch.


I have been at many places, in many teams, where no-one has ownership of the build scripts. It’s an area where a company can bleed a vast amount of time and money without realising it. It  may even be what makes senior member leave in the end due to frustration with to much inaction.

What is unfortunate is that it is relatively simple to fix. Sure, there are risks associated with any legacy clean up. But getting the build to work is far simpler then many other tasks in a legacy codebase. I find that the main reason it is not done is that the team can't communicate the value to management (including product owners). Therefor it gets low priority and ends up at the bottom of the back log.

I have always found that one of the best ways to communicate value to management is in money. By putting forward a business case with a clear RoI (return of investment). When it comes to build scripts this is a pretty easy task. First, ask everyone on the team who uses the build scripts to keep track of how much time they spend doing build related stuff. How much time do they spend working around a broken or non-functional build. Try to count only time which is spent unnecessarily. Once you have enough data to know what the broken builds costs on a weekly/monthly/quarterly (which ever suites your needs) basis it is time to look at how much it will cost to fix the build. I suspect the ratio will be quite scary. The difference is how much you loose each week/month/quarter. Hopefully this should get managements attention and priority.

Now that fixing the build is top in the backlog we need to make sure it doesn't fall back into despair again. This is where ownership comes into play. In a well functioning self organising team this is never an issue. Everyone owns the build. Everyone makes sure the build is just as snappy as everything else.

But If you don't work in senior or self organising team? Who should be responsible? A good place to start is the team. Perhaps someone feels very strongly for it. Passion goes a long way. Granted, you can't have just one who owns the build. It is knowledge which is far to important not to share between at least two. But with one lead it's usually easy to follow. Make sure to pair often to distribute knowledge.

If it's difficult to find someone who wants to take responsibility the team should make sure to pass it around. Share the pain to make it lesser for everyone. The main responsibility will however always fall on the architect. A working build is part of the non functional requirements that makes up an architects main concerns. How will you as the architect be able to guarantee that the solution you are the master builder of will ever reach it's intended user or customer if it cannot be built?

Now, go and fix that build and remove the pain. It is so worth it. And remember, with a working build you'll have so much more time to code, and that is what's really fun!