Comments on: Technical Debt

By: mheusser

mheusser — Tue, 24 Mar 2009 19:48:01 +0000

I think we use different rhetoric, but this is essentially a sub-selection of my opinion on tech debt. Oh, there are different dynamics and possibilities involved, but, in general, this is solid advice i’d support.

–matt heusser

By: Dirk Riehle

Dirk Riehle — Sun, 22 Feb 2009 02:35:02 +0000

Manuel Klimek pointed me here.

If the financial metaphor is apt, and the customer is like an investor, then you should disclose any relevant liabilities, of which technical debt would be one.

Dirk

By: jonkern

jonkern — Sat, 21 Feb 2009 03:45:58 +0000

Regarding “…some folks’ notion that it is OK to write the program a little less well with intention to clean it up later… He [Ward] says that the program as written should always reflect all of our understanding of the problem and the solution, as of the time we wrote it.”

How can it not? It certainly cannot reflect more than your understanding.
Or, conversely, how can it ever truly reflect all of your understanding?

I can guess that Ward means “Don’t do something stupid and leave a turd in the program.” Which of course presumes that the developer knows in the first place what constitutes quality design and good coding.

Not sure where these fit in to the continuum that represents Ward’s comment…

1) Many times I have the opportunity to “grow” a feature over time. Though I might have a long-range vision that meets business needs, we have the ability to release a subset of the whole and achieve business value sooner than were we to implement our entire understanding. Of course, some of the understanding involves realizing that we can get value with less. So, because I think this is a smart thing to do, maybe it doesn’t fail ward’s test.

2) Once in a while, I will jam out a feature with some potentially ugly code because that is the best choice to get it out the door. Getting it out the door is a big win for the business/product. This allows me to get value now. But we then immediately come back to this hack to refactor and do it right. This allows us to avoid technical debt in the future.

Never say never.

But guidance of good things to do when given the chance is always a good thing, as you and Ward are trying to do. However, hoping that all developers know how to best balance their efforts to the current understanding is a conundrum.

– jon

By: mabotelh

mabotelh — Thu, 19 Feb 2009 18:03:54 +0000

“Can every refactoring be done inch by inch, step by step (slowly I turned)? Well, yes.”

I think that the inch by inch approach work for most of the cases and in my experience has been the best approach.

One case where this can be hard to accomplish is when your “refactoring” is very radical, perhaps in the order of switching from say Java to .NET.

In this case you can be put in a position of having one foot in the boat and one on the shore. Not stopping traffic like you mentioned in your post might mean a quickly rising technical debt.

Could you please elaborate more on this topic?

Mauro

By: Sebastian Kuebeck

Sebastian Kuebeck — Thu, 19 Feb 2009 16:46:18 +0000

> Sorry. We do have to tell, because we want everyone on the team,
> including the customer, to know what is going on.
> We just don’t have to ask permission.

I think you are perfectly right!
Alan Cooper says in a different context that you should never ask your user (or customer) to design the application themselves…

http://www.youtube.com/watch?v=sNWBnCazIcU

I think it’s the same with refactoring. It’s the developers job to find out when to do it and why.

Sebastian