Documente Academic
Documente Profesional
Documente Cultură
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!
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.
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.
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.
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.
7|Page
www.ontechnicaldebt.com