Joe Schaefer <joe_schaefer_at_yahoo.com> writes:
>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.
Not sure I should respond, but:
First, patches welcome as always. Second, while I had time to have the
(IMHO useful) discussion with Mark, I don't have time to code right now.
It's not like the alternative was that I'd be writing code (sadly)! :-)
-Karl
>----- 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-18 16:02:05 CET