What I would like to see from this project is less arguing
about irrelevant concepts and more features in the working
copy, ideally to make fewer network trips for better performance
or to support queued commits so sysadmins need not panic over
work stoppages due the the central server being down.
----- Original Message ----
> From: Mark Mielke <mark_at_mark.mielke.cc>
> To: Karl Fogel <kfogel_at_red-bean.com>
> Cc: Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu>; Mark Phippard <markphip_at_gmail.com>; Subversion Dev <dev_at_subversion.apache.org>
> Sent: Sun, January 17, 2010 10:31:47 AM
> Subject: Re: Subversion in 2010
>
> 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
Received on 2010-01-17 17:34:52 CET