On 01/17/2010 02:55 AM, Karl Fogel wrote:
I'm *totally* trolling now, and I'll own up to it... While I actually
agree with a lot of what you've written in this thread, I think this
conflation of bugs with tech debt is a mistake. They're not the same
thing at all. I almost wrote that in a reply, but then realized that
I'd seen this often enough that -- help me, I have truly gone to the
dark side -- I thought it might be worth a blog post. So:
http://www.rants.org/2010/01/10/bugs-users-and-tech-debt/
It would only be proper to flame me there, I suppose :-).
Seriously: I don't think the SVN project, or any other project, should
treat the bug list as tech debt. It's not.
Lots of good points in there, but I think the underlying different in
perspective comes from our definitions of a bug.
You suggest that a bug might include new features or enhancements, or
that it might include anything that behaves differently from how the
designer expects it to behave.
A good and well resourced designer should already understand how a
particular piece of implementation will behave in each possible code
path or use case. In the case that they do not, this means they skipped
a step, or incurred technical debt, in a means to deal with some other
imperfect situation such as lack of resources or lack of full
understanding of what they were changing.
Another argument could be that the technical debt has no impact on the
users, and there is no intent to pay it back. I think this could be a
design decision that was made to limit the capabilities of a feature
from the start with no intent to ever extend the capability. This is a
bit fuzzy as the users may not agree with the design decision - but
"bugs" to extend the capability should probably be closed immediately
with "No intent to fix", meaning that they do not fill the product back log.
There are other sorts of bugs that are so low priority that they will
never be attacked. These also should be closed as soon as it can be
decided with "No intent to fix." They introduce noise in the product
back log and prevent reviewers from being able to rank the issues
effectively. In a corporate policy we had once, any defects that were
not going to be scheduled for the next release, or the next release + 1,
could be closed as "No intent to fix".
To contrast your conclusion that more bugs means more users which can be
good, I'd like to point out that having more users means that each bug
has the potential to affect more users. More users means existing
technical debt has more impact, and is more desirable to be addressed.
In any case, on a issue by issue basis, we could probably say "100%
technical debt" vs "100% new development request" vs anywhere in between
- but my intent in mentioning it was to point out that:
1) If a project becomes overwhelmed with technical debt (however
defined), it can and will stifle new development. The designer resources
available are split between working on old and new instead of being able
to work together on new.
2) If new development is introducing defects faster than they are
being fixed, this is a recipe for product failure.
I also think that "more bugs" only means "more users" in the sense that
they are more use cases which are exposing *already existing* bugs.
Assuming it is truly a bug, and not a design limitation or feature
request (unexpected vs expected behaviour perhaps), then the technical
debt already existed. The user base was just too small to expose it before.
All said, I think you and I might agree more than disagree, if we were
to actually identify on an issue by issue basis, which "bugs" are
technical debt vs design limitation or feature request. It seems to me
that terminology is thekey difference over a subject which does deserve
discussion in every project which is serious about ensuring customer
satisfaction.
Cheers,
mark
--
Mark Mielke<m...@mielke.cc>
