Going fast is making things worse - Interview with Michael Feathers

itemis was pleased to host the workshop “Working Effectively with Legacy Code” by the author of the book by the same title, Michael Feathers. During this workshop we had the opportunity to conduct an interview with Michael about his ongoing work with legacy code and beyond.

Hi Michael, thanks for taking the time. We start the interview with a question you probably have been asked a lot: What is legacy code?

Legacy Code is a term so we can define it in many ways. I am known for this definition of legacy code where I said: “Legacy code is code without tests.” The original sense of the term is, that it is code that you got from somebody else.

The reason why I defined it as code without tests, was that I think it is a good way for people to see their way out of the problem with legacy code. Having tests for your code gives you the opportunity to extend your software with real confidence.

We always asked ourselves: Does Michael Feathers write legacy code in some situations?

Yes definitely, mostly for my personal projects when I am prototyping and trying out different things and see what’s gonna happen with them. Even if I don’t do Test-Driven Development (TDD), if I am working on a piece of code, that I feel will be useful, I do write tests afterwards, though.

When working with teams, I try to motivate them by saying: Hey, let’s try writing tests first with this, to bring the experience forward, because there are a lot of people who don’t have the experience with TDD yet.

A lot of developers are working with legacy code on a daily basis. So it seems that writing legacy code is still common today. What do you think is the reason for this?

There is a couple of different levels on which we can approach this question. One is that quite often in the software development processes, there is no way for information about technical debt to get acted upon. One option here is to be very visible about the health of the system at the code and architecture level.

When a new feature is requested, a developer could say it will require four days of work because it touches these four components, two of these are healthy but the other two are not as healthy right now - which explains the required development effort. Then the health of the system is part of the conversation.

I believe that having such discussions within an organisation is extremely valuable, because it is pretty easy for us to abstract away from that and just believe that pushing developers harder gets you more.

What really happens is that sometimes going fast is making things worse.

Infrastructure as code is a hot topic in software development today. Do you see infrastructure as code as a new growing area of legacy code?

If you want me to be very realistic I will say yes. Because that is the way things move.

But when you are writing code, all of your code should be production code. If it is part of your infrastructure you need to be in a situation where you are able to change it easily, the same way we want it to be with our production code.

So are we missing testing tools for this infrastructure code?

I think so. There are a lot of scripting tools, where people do not really have good testability tools for yet.

Back to testing in general, why would you say that testing is still not a first citizen in software development?

It’s a lot of work. I think that’s part of it.

The sense I have is that TDD really only connects with people when they kind of painted themselves into a corner once or twice in their career. Getting to the point where they can’t understand what is going on in their code and they are scared. Having that experience helps you understand what proactive measures one can take as a developer in order to make sure that never happens again.

I want to add to this as well - that I am not really sure that the languages and environments we have right now incentivize us to do TDD or even make our systems testable. I think there is probably more work we can do with this.

TDD is strongly connected with good software design. Do you think there are alternatives to come up with similar results without writing your tests first?

Experience. The best developers I have ever met tend to be very reflective on what they do. Many of the design principles came from the observations of very introspective developers discovering these things. So I think it is possible to end up with a good software design if you have internalized design principles and experience.

The nice thing about TDD is that it makes deviating from these things rather painful, so it is a good way of reminding yourself as you grow.

TDD can also be very helpful if you are working with people who do not have not much of this internalized design-sense. They will have pain when they are writing tests and you can help them frame why it is painful.

The important difference is that testing is not intrinsically painful. Many people think that testing is always painful because they are writing tests for existing code - and that is painful most of the time, but it is painful specifically if the design is not test-friendly. So testing in general is not painful but testing in the presence of bad design is painful.

If people write tests as they go, some of the design problems tend to go away and things become easier.

What is your opinion on different TDD flavors such as the recent idea by Kent Beck, test && commit || revert.

I think it's interesting. I think he put that out there as an experiment. One thing which is really powerful and important: I love working with teams where they are willing to do experiments like that. We want to understand more about the process of programming, so why don’t we try this and see what happens. I think that is a really valuable thing.

There is a lot of routine work that happens in software development. If you enjoy programming than you are going to be curious about things and you want to try things out.

We have seen a lot of different variants of TDD over the years, but there are probably a lot more to discover. It is just a matter of people getting ideas and trying them out.

Speaking of interesting ideas, what are the topics in which you are most interested in these days?

I am very fascinated by patterns, that exist in more than one domain. I am not talking about software domains strictly. There is something called Postel's Law - the idea is that if you are building a system out of individual connected pieces, it is wise to make them liberal in what they accept and conservative in what they produce. When you do this, things tend to fit together very well.

Lary Wall who designed the Perl programming language observed that the same thing is true with people. Let's say you are at a party and talking to people. It's nice to listen to people talking and not be too upset by anything - then you are being liberal in what you accept. But, you should be careful what you say so you don't hurt other people's feelings. It’s fascinating that this principle works for software and also works for social systems.

I think that there are many things like this, which are worth exploring.

Thank you Michael.

Interested in a course about techniques that can be used to introduce test scaffolding, refactor, and optionally replace critical code that is hard to work with?