Ultimate Quality 功夫 System

[glyf]

Often it is the means that justify the ends: Goals advance technique and technique survives even when goal structures crumble.

- Alan Perlis, Epigram 64, "Epigrams in Programming"

How does a computer programmer get better at computer programming

Comments

[corydodt]

Where I've found UQDS intimidating, it's been because of the slowness of the procedural hurdles, not the difficulty of doing it or the cross-programmer interactions required.

So how can we get a 10th-dan ninja on our side? I want an API for exploding heads. Maybe some kind of Amazon Mechanical Turk thing, but with psychic ninjas on the other end.

[glyf]

Writing in this arbitrarily changeable format is tricky. I had a whole section comparing the procedural difficulties to unpleasant aspects of training, but I cut it out because it was getting up into the "dozens of pages" size range. Briefly, while it's fun to watch two guys with crazy kung fu skills fighting at lightning speed, it's not so much fun to sit in horse stance for five hours and then keel over, unable to walk for a day.

Similarly you'll note that I placed an emphasis on the fact that this looks impressive from the outside. If you're in Divmod or the Twisted community, it's just the way things are getting done, and it has pros and cons.

As far as the ninja thing - I'm having trouble just finding a guy who can do HTML. We might have to wait on getting one of the most elite assassins in human history to commit murder for us for free.

[corydodt]

Doesn't have to be free. $0.20 per kilosplode?

[puzzlingspiv]

Despite their drawbacks, these rules plus a public ticket tracker add up

Like at http://www.divmod.org/trac/wiki/UltimateQualityDevelopmentSystem, you make this assertion, but I think you're confusing a mechanism with the reason why it's valuable. It's not important that you track work in a ticket tracker (or even that you use branches, except that decent version control tools make branches easier to manage than patches). It's important that there is an obvious place to discuss a proposed change (and a place to propose a change), and for example a dedicated reviews mailing list (and a wiki page for tracking review requests) can work just as well. I haven't looked closely yet, but http://www.review-board.org/ looks like another reasonable way to track and discuss reviews that doesn't inherently involve a ticket tracker

[glyf]

Like at (the UQDS page), you make this assertion
I am a little confused. First of all, what assertion? I don't say anything on the UQDS page about the benefits of publicly displaying review discussions, which is really what I was talking about in that sentence. I assume from context that you mean my mention of a "ticket tracker". Second, I'm a little surprised at the apparent emphasis of your tone - I wasn't really aware that you'd raised this objection in the past, but clearly you've brought it up before since you say it's never been answered.It's important that there is an obvious place to discuss a proposed change (and a place to propose a change)...
As far as I'm concerned, that is basically the definition of a "ticket tracker". You've got some work (a ticket) and you track (discuss, annotate, describe) it.

You can use a mailing list as an ad-hoc ticket tracker, and that might be the only thing that was actually worse than the mess that is Trac ;-). In the context of this particular essay, though, regarding the effects of

Reply 2 of n

[blackjml]

> > It's important that there is an obvious place to discuss a proposed change (and a place to propose a change)...
> As far as I'm concerned, that is basically the definition of a "ticket tracker". You've got some work (a ticket) and you track (discuss, annotate, describe) it.

A change to software involves, at least:
* A reason for the change (+ discussion)
* A description of the change that needs to be made (+ discussion)
* A plan for how to make change (+ discussion)
* The changed code (+ discussion)

UQDS only mandates that the reason for the change (i.e. the initial bug or feature request) be recorded, along with a discussion of the changed code. It also provides a structured way to link from the discussion to the code itself.

In Twisted and Divmod practice, features are rarely specced out on Trac. They are more often specced out informally on mailing lists and on IRC.

I guess what I'm saying is that ticket trackers aren't all that.

Waxing philosophical

[smitty1e]

I like to look at the fact that information is a fluid.
We carve it up into discrete chunks to manipulate it in RAM and persist it on media, but that is an existential necessity, not an essential truth about the information.
If you look at books on programming language theory, and I have a couple, though I've only even done one toy project that gets into parse/lex ideas, there are a dozen or so concepts that are common to languages. That's it. Nothing more. A MicroSoft can trot out a Delegate or something, but it's all been done.
At the architecture level, you have the GoF book, and its 20-something patterns. What are they all about? Figuring out where to put the state.
Have you looked at Haskell? While I'm a n00b there, too, I must say its radical distinction between pure and stateful is a real mind-ripper.

Re: Waxing philosophical

[smitty1e]

Shouldn't have used the word 'fact' in the first sentence. That was an opinion.

[jkakar]

As far as I can tell we're pretty much using UQDS on the project I
work on. When I first started this job one of my coworkers said
something like, "I believe a good programmer is one who likes to read
code." At the time, I had little experience reading code and
generally found it an uncomfortable activity. It was an interesting
comment though, and the more I thought about the more it made sense.

Having now been involved in a project with a strict review process for
a little more than a year I can confidently say that my ability to
read and comprehend code is significantly better than it was. My
ability to write code has also improved but I believe mostly as a
result of better reading comprehension.

Reply 1 of n

[blackjml]

In line with corydodt's comment, I don't find UQDS intimidating. I find it painful. It's hard work with few immediate rewards. This is because I'm fairly confident of my abilities as a programmer.

I haven't done very much physical training of any sort, let alone kung fu. I find it to be both intimidating *and* painful, because I lack confidence in myself and because it's hard work with few immediate rewards.