Related link: http://groups.yahoo.com/group/extremeprogramming/message/91683
A common assignment type in creative arts classes is to produce a work in a
specific style on a specific topic. For example, a poetry class might have to
write a
vampires. A painting class may produce watercolor still lifes. A composition
class could write a three voice canon and a songwriting class will sometimes
write a silly song in the AAA form.
These assignments rarely produce commercially viable or artistically elite
work, but they’re effective at exercising creative muscles. I think that the
constraints enforce some editorial judgments. For example, if you had to choose
the right six words to describe vampires as in the case of the sestina, you’d
have to choose the right six words, if you wanted to write a good poem.
Consider also the case of writing a three-hundred word horror story, especially
if you edit it multiple times. Every new word requires the removal of another
word.
It’s obvious that you can take this idea too far. Arguably, since there’s
already one good vampire sestina (see Neil
Gaiman’s Smoke and Mirrors), the subject’s tapped out. If you
have existing constraints, though, of color, form, line length, meter, or word
count, does that save your creativity for more interesting problems?
In the introduction to
Guide, I argued that successfully adopting XP requires adopting an attitude
of sufficiency. Instead of assuming that you don’t have enough resources to do
everything you think you need to do, assume that you have enough resources to
do what you can do — and scale back what you need to do to what you can
do.
In a recent post to the XP mailing list, Ron Jeffries suggested that you can
start
practicing XP by adopting the practice of Small Releases. That is, if you
force yourself to produce a release every two or three weeks, you’ll need to
adopt most of the other XP practices (or reasonable equivalents)! You don’t have to make your customer upgrade every two or three weeks, but his needs should govern the choice, not the stability or quality (or lack thereof) of the code.
Even though I’ve been writing and writing about software for a while, I’m
still amazed at how projects can drag on and on until someone with authority
gives a final, drop-dead date. (Hey, open source development isn’t immune.
Witness the length of time between Debian GNU/Linux or Linux kernel stable
releases!) It often takes a burst of activity (and, unfortunately, a death
march or two), but the software finally arrives near the deadline.
I’m deliberately leaving aside the questions of quality, customer fitness,
stability, and maintainability from this argument — I think XP-like
practices definitely help here — but I often wonder lately if trying to
produce more frequent releases by doing everything except releasing more frequently is misguided.
Perhaps we don’t need long development times because software’s so difficult
to write. Perhaps software’s so difficult to write because we have such long
development times.
Thanks to Adrian Howard for the pointer to the mailing list
message.
Not all artificial constraints are harmless, but could the helpful or neutral ones help us produce better software more reliably?
Sestinas in action
Sestinas in action.
code quality no longer important????
You don't have to make your customer upgrade every two or three weeks, but his needs should govern the choice, not the stability or quality (or lack thereof) of the code.
You advocate putting the release schedule ahead of making sure the code that actually gets released is stable?
Because that's what I read in your statement here.
Of course customer needs should govern what gets written, if it doesn't the product won't sell in today's competitive marketplace, but that should never mean just pushing out code no matter whether it's stable or not.
code quality no longer important????
It's not clearest of sentences but I think the point being made is the complete opposite of your interpretation. I think what is being said is:
Following the XP approach, you should have regulary stable code points ('releases') say every two or three weeks.
But if the customer wants to upgrade every six months, or when features X, Y + Z are complete they can do so by choosing one of the releases that best fits their time/feature requirements rather than mirror the developer's rapid 'release' schedule.
And if they change their minds and decide that they need to upgrade *now* and can live without feature 'Z' then they can be sure that the code will be stable and release quality (or at most 1.5 weeks away from a stable point in either direction).
code quality no longer important????
That's right. The sentence is terribly unclear, but I meant that if you keep your code in a stable, releasable state, your customer can upgrade on her own terms without having to wait for your code to reach a stable point.
Tighten those feedback loops
Perhaps software's so difficult to write because we have such long development times.
Yeah, that pretty much sums a lot of problems up. As soon as you start tightening the feedback loop you start getting better code faster.
You see the same affect in lots of agile practices. TDD tightens QA feedback. Pair programming tightens code review feedback. Release planning tightens user feedback. Iterations tighten project management feedback, etc. etc.
Since adopting more agile development practices I find myself looking around for ways I can get input on whether I'm doing well/badly more quickly. Less feedback more often is good. You can associate cause and effect more easily.
(OT Moan: why the heck can't we get RSS/Atom feeds for these darn discussion boards :-)