Michael Feathers Interview on Technical Debt

Adapting IT organizational process in software development

Welcome to the OnTechnicalDebt Expert Interview series!

Today we are here with Michael Feathers, former member of the technical
staff at Groupon, prior to which he was the chief scientist at Obtiva and a
senior consultant with Object Mentor International. Today he is an
independent consultant and spends a great deal of time helping teams alter
design in large code bases. Michael is also the author of the successful book,
Working Effectively with Legacy Code.

We are also here with Carolyn Seaman, who will be leading the interview
she is an associate professor at UMBC where she is the leader for Technical
Debt research studies (http://www.technicaldebt.umbc.edu/). She is also a
Research Fellow at the Fraunhofer Center in Maryland. Lets dive right into it!

1. Defining Technical Debt in Todays Industry

Carolyn Seaman: As you know, the term Technical Debt has been around for some time.
Although it has been used more recently, its been around since 1992 when Ward Cunningham
first coined the term. He described it as a software design metaphor that highlights the
compromises between short-term gain of getting stuff done quickly and the long-term viability
of software. But that definition has evolved over time; its been picked up by the developer
community and even more recently by the research community.
So first, I would like to ask you what you think of the way that that term has been picked up in
the industry.
Michael Feathers: The thing that Ive noticed is that this is one of those terms which start out
having a very specific definition but then the community picks up on it and it becomes more
general. And I think that has definitely happened with the term Technical Debt. When Ward
Cunningham first described it he was talking about something that developers do consciously in
order to meet short-term goals, where they then go back and correct the problems in the code
1|Page

www.ontechnicaldebt.com

later. Having talked to developers over the years, what Im noticing is that Technical Debt has
taken on this definition of anything that causes less than ideal design. And its really confusing
because Ward had a very crisp idea of what he was talking about So using this same term for
the general reduction in the quality of code is really confusing. I think that both of them really
do deserve terms.
Carolyn Seaman: So what is your current working definition of Technical Debt?
Michael Feathers: I dont know! I think I would go back to Wards definition and I would like to
be allegiant to that. But I do recognize that the term is used in a far more expansive sense
today. And I am using the term Technical Debt today for just about anything that applies to an
entropy within a codebase. But it does feel like a less than ideal term to use for that.

2. Organizational Structures for Technical Debt

Carolyn Seaman: In 2008, you had a blog post Beyond Technical Debt, and in other
presentations too, youve discussed how we should be looking that this concept in a slightly
different way: one that takes peoples behavior into account. Could you say a little more about
that and how that would be possible? For example, is there an optimal organizational software
development structure that can help to enhance the reduction of technical debt?
Michael Feathers: In terms of an optimal organizational structure, I think the thing that we
probably might get too, and that I hope we get too, is the recognition that there may not be
one. I dont mean to sound pessimistic but I dont know how familiar you are with Conways
Law? It was put together back in the 1970s by a guy called Marvin Conway who essentially said
that when you produce software, or any other design or artifact, in essence it is going to mirror
the structure of the organization youre in. And that points to a deep synergy between
organizations and their design artifacts. I think that this is true and when you look at the
ratifications of that, you realize that in order to go in and alter a design, you have to make
organizational changes. And it cant be a one-shot thing; it has to be truly responsive to what
you want to do. I participate quite often in conversations about the organization of teams and it
is the case that people want to try and find an ideal structure. But I think its better if we set up
responsive structures.
To give an example: one thing that people go back and forth with in the Agile community these
days is the notion of having dedicated component teams that basically work on separate
domains in the software, versus having teams that are just groups of people working on
random features that come in. And if you look at it, you do have quite different effects on the
code base based upon which type of organizational style you have. And my thought on this is
that neither one of these is perfect; you need to be able to strategically switch between those
2|Page

www.ontechnicaldebt.com

in order to achieve the effects that you want to achieve. And that involves looking at the code,
and understanding what the effects of the organizational structure are on the code. I think that
it is a level or awareness that organizations do not really have yet in software development.
Carolyn Seaman: How does that relate to Technical Debt? Are you saying that a more
responsive organizational structure is less likely to incur technical debt, or does a better job in
getting rid of it once it has occurred?
Michael Feathers: It seems that Technical Debt, at least in the broad sense, is inevitable. Things
will quite often be placed in the code bases that are less than ideal. But the question is: how
soon do you recognize them, and what are you able to do in response to them. For instance,
when I mentioned the notion of component teams and feature teams, one thing that has been
observed is if you have a group of developers working on one particular area with very strong
domain knowledge for a period of time, sometimes you will get some deterioration of design
just because the people working on it have internalized so much of the design; they dont
necessarily notice that things have fallen off from the ideal. Its like when you are working on a
code base for years things that seem clear to you might not be clear to people looking at it for
the first time. And thats just a natural acclamation. I guess we can look at that as being an
aspect of Technical Debt. Someone from the outside might look at that code and say, well, this
is grungy code and I wouldnt do it this way or something along those lines. But that really is the
side effect of having one team working on that area for a long period of time and internalizing a
lot of knowledge about that area. So for me that ties in: code reflects what we do with it and
from some perspectives that less than ideal state can be seen as Technical Debt, at least in a
very broad sense.
Carolyn Seaman: This brings us to the point of Agile and highly iterative environments that do
have a highly responsive structure. It has been argued before those structures do deal better
with Technical Debt because it is part of the process. Do you look at it this way: the more Agile,
the more responsive the process is? Does that lead the organization to create better ways in
dealing with Technical Debt on an on-going basis?
Michael Feathers: When you say Agile, again, this is another one of those terms that has a
very specific meaning, but a very wide one at the same time. Agile as practiced in the industry
tends to be one of several processes that have been around for a while. They can be practiced
in a very rogue way or in the spirit of Agility way (which basically means having an extremely
reflective process where you are looking at a wide variety of indicators and making decisions in
the moment about what you want to do, if you want to alter things or make things better).
What I find kind of awkward about Agile today is that in many cases there is not a strong
awareness of code quality in many teams practicing Agile. It is more along the lines of saying,
well, OK, we have these features that we need to have in the code base, and we need to deliver
3|Page

www.ontechnicaldebt.com

these features so what do we do in the organization in order to make that happen. Here
were not looking at the effects of the overall design.
Im hoping that people can use Agile in the spirit-of-Agile way and recognize that they need to
be very responsive all the way through their development.

3. Technical Debt as a Business Asset

Carolyn Seaman: Youve also argued in the past that we should be considering the quality of
the code itself as an asset. In the context of talking about Technical Debt, how does that work
and what do you mean by that?
Michael Feathers: I think that sometimes we do not appreciate well enough that the quality of
the code we are working on does have a strong impact on our ability to delivery features later
in a timely fashion. Quite often organizations that are not looking at the impact of adding
particular features in a particular time will suffer in the end. What that comes down to is
awareness. If you have a very large code base, you cant just look at it saying, Here is the code
we have written over time that we have in the organization when it is in fact something that
is going to impact future decisions that you make. Seeing it as an asset is really an important
aspect of that.
Carolyn Seaman: I want to talk about something else that you often mention: The evolution of
the software system as an organic process and in some sense happens naturally. What does this
mean for Technical Debt? One way to interpret that is to say we have to accept Technical Debt,
that it is a natural part of the evolution process and will always exist. And we should not try to
eliminate all of it. Is that the right extension of what you talked about as software evolution
being organic?
Michael Feathers: I think so. But it comes down to whether you accept the broader definition
of Technical Debt or not. We were looking at it in a very strategic sense (i.e. Ward Cunningham
first outlined saying that this is something you do to meet short-term goals and then you
correct it later). Thats one thing, but in a broader definition we just say that we are surrounded
by code that is less than ideal.
The thing that I am coming back to when I say that this is an organic process is that there are
things that we need to recognize One is that the changes that we make in the software
process are quite often those that we will live with for a long period of time. Its like having a
tree in your back yard for instance, if you kick it, it will be at an angle and in essence will grow in
that direction. It might go ahead and compensate for the fact that you kicked it but will never
correct itself totally. This is the natural consequence of the way that we develop software when
we have an existing system or making modifications based on stuff that we already have. In
4|Page

www.ontechnicaldebt.com

essence, it is a form of entropy incremental growth. In most cases you do not just march in and
completely correct an existing architecture because it costs too much that do that sort of thing
typically. So you are consistently going in, working with what you have, and making incremental
change. And with anything that we do as human beings that involves incremental change tends
to have a bit of an organic feel to it.
Carolyn Seaman: Yes, that makes sense.
Michael Feathers: I think its very different from quite often the view that people have on
software development: you hand something out, you target a particular end state, create
something, and then when the design is done you move on. And this is a very nave view of
what software systems are. When you create something it is going to be a target that people
change and organic change is going to be part of that.

4. Communicating & Dealing with Technical Debt

Carolyn Seaman: Lets move on to what Technical Debt looks like on the ground. Youve had a
lot of experience with different types of software teams dealing with large code bases and
were very interested on how IT teams should be and are dealing with Technical Debt.
Do you find that in practice using the Technical Debt metaphor to facilitate the communication
about technical issues with business holders is effective? Are people doing that in practice?
Michael Feathers: I do see that. Its funny because sometimes the conversation occurs in those
terms and people try to use the monetary metaphor Often people try to quantify it and speak
of Technical Debt in financial terms. But I havent seen the quantification aspect be very
successful. But as a metaphor I think it works very well as it shows that it is going to cost us
more later on. Actually going in and attaching dollars and time periods feels more like a hunch
in many cases to me. I think the main reason for that is because often we do not know what
features need to be changed, and therefore it is hard to really understand what the financial
impact is going to be on that particular strategy right now.
So I feel that its nice for talking about those technical things, but the quantification aspect is
something that Im a little apprehensive about it. Its great when you talk about it as a
generality, but if you try to carry it too far and try to quantify things, we could get into trouble
Carolyn Seaman: What do you mean by getting into trouble?
Michael Feathers: Essentially throwing around numbers that do not have a real meaning. If
people understand that this is just a guess then thats OK. But will people believe in these things
if there is no real basis for it?

5|Page

www.ontechnicaldebt.com

Carolyn Seaman: Do you think that if we were able to quantify Technical Debt effectively and
come up with some numbers that really have some meaning behind them and that people
would trust, would that help around communication on Technical Debt? Or do you think that
quantification is not important?
Michael Feathers: Thats an interesting question I think that Im a little suspicious of the idea
that we can quantify this sort of thing an effective measure would rely upon future features
that we might not be aware of. If we could quantify it in a way that would be useful, then yes, I
think it would be rather valuable.
The thing that I lean towards more these days is a non-quantitative way of looking at things a
representation that we can use to communicate back and forth between business and technical
people. For example, look at this picture which shows you how clean things are in the code
base and why certain things are taking longer. And here is a picture of what our code base looks
like after this episode of development and you can see that we had to do certain things that are
not quite great in order to go and make this sort of thing happen. I feel like it can be used in a
non-quantitative way. And my gut is it that might be a very useful avenue to take for this sort of
thing.
In order to have a meaningful quantification, as I mentioned, we need to take into account the
costs of future features. The one thing I am terribly suspicious of right now is the notion of
taking a particular ideal state of code, and quantifying Technical Debt in terms of the distance
between the current state of the code and ideal one that we have in mind. It feels very artificial
to me. This might be a result to experience over the years noticing that there can be some very
awkward code bases with lots of deviations from the ideal, and there are cases where
deviations go in very easily and there are cases where they dont go in quite so easy it
depends upon the particular feature set and some local criteria. At that point, it almost makes
the notion of an absolute measure of Technical Debt kind of obsolete it makes me wonder
about the value of it.
Carolyn Seaman: What would you say to an IT team that has really not been thinking about
Technical Debt and havent been dealing with it, but have come to realize that they have it?
What are the questions that they should be asking themselves in order to figure out what steps
to take?
Michael Feathers: Its a choice to see code in a different way. They should be continuing asking
themselves prior to an episode of work, What do I anticipate the state of code is going to be
like afterwards? Not in terms of actually visualizing what the code is going to be like, but more
about how you plan to leave the code: youre adding a feature, at the end of the episode, will
the system be worst off or better off? And thats the type of thing we need to try to do all the
6|Page

www.ontechnicaldebt.com

time All the while keeping the Technical Debt metaphor in your mind and saying, We want to
leave this code better than it was when we first approached it.
Beyond that, go in and have that conversation with stakeholders: we can do things in a quicker
way but things are going to be worse off if we dont supply the effort as we go and make sure
that things are improving. It is really a conversation style more than anything else in my
opinion.

5. Technical Debt Key Point

Carolyn Seaman: Any last thoughts that you would like to share with our listeners?
Michael Feathers: Earlier you asked the question about seeing software as an asset, and there
is something that I wanted to say a bit more about. There was a workshop on Technical Debt
years ago with some people in the industry Brian Marick, Matt Heusser, a couple of other
people and one of the things that really annoyed me at the time when we were discussing
technical debt was that I felt we might get a bit more leverage if we flip the term around
When we talk about debt in financial terms, one thing that credit card companies understand is
that if you arent really parting with your cash at the moment it is easier to incur debt We
pass the plastic card to somebody and they pass it back to us. Financial advisors always say that
one way of being very conscious about what youre spending is to actually use cash. It is a
physical feeling of passing your money over from your wallet and not getting it back. Ive heard
that people tend to not spend as much when they are paying with cash.
It makes me wonder about this when it comes to Technical Debt Weve talk quite a bit about
incurring Technical Debt and I wonder sometimes if we are not too in close to the notion of
debt. Perhaps another way of looking at things is to say that this particular software that we
have has value and we could look down the path of quantification and stuff along those lines.
But it might be possible to frame the conversation with stakeholders and say: your software is
this much valuable and if we do things this way we are going to lose this much value (as
opposed to incurring debt). Its a bit of an inversion of the terminology but I guess it is trying to
play off the notion that people are more loathed to lose something than to take something on.
I havent really done much work around it but to me it seems like an interesting avenue that
might be worth considering. If you really want to carry the monetary metaphor forward, then it
might make sense to go ahead and assess the value of software and how much of it can be lost.
Carolyn Seaman: Thats a really interesting idea. I had never thought of it that way! Thank
Michael, it was a pleasure.

7|Page

www.ontechnicaldebt.com