CMSish

where web content management and user experience collide

Always wrong is doing it right

On an agile project—and is there another kind these days?—being wrong is no big deal. It’s usual, even. You might as well get used to it. You’re wrong because:

  • You don’t have all the information to hand at the outset.
  • You don’t have time to wait for all the information you need.
  • If you waited, the requirements would change anyway.
  • There’s usually more than one way to tackle a problem, and the best way often isn’t clear up front.
  • You might know the right thing to do, but have to descope or hack it in order to hit a deadline.

That last one is after all a key aspect of agile: the trade-off you make to achieve hard deadlines is to jettison functionality. Leaving you wrong by design, as often as not.

So you’re wrong. Then you iterate, and with each iteration you’re less wrong. But you probably never eliminate all the wrongness. The requirements change again, or it’s simply not cost effective or a good use of your time to go back over something that’s wrong but good enough.

A great current example is the iPad. It’s so full of wrongness, missing so much functionality that you might naively think it couldn’t possibly go to market yet. Want to transfer a document from one app to another? Want to style some text in any app whatsoever apart from Pages? etc. It’s funny that Apple explicitly rule out “beta” apps appearing in their App Store; well, unless you consider all apps are always beta, because they’re always wrong. But actually the iPad has more awesomeness than wrongness, and the former more than makes up for the latter. They’ll sort the bad stuff out later, probably.

Which leaves this problem: it’s human nature to dislike being wrong. Even worse to be told so. We all know developers can be a, erm, stubborn bunch convinced of their own innate correctness, who find it harder than most. For sure I count myself in that camp.

I wonder whether this isn’t one of the harder virtues of the agile developer: to be able to live with being always wrong, and not mind having it pointed out where necessary.

PS. Yes, sure, you can also be wrong just because you’re, well, wrong. Because you’re a dumb-ass and clueless. otoh you might get lucky with your project and be 100% cast iron right from end to end. So I should really have titled this post “If you’re not always wrong you’re probably not doing it right”.

Advertisements

Filed under: Development,

2 Responses

  1. Jon Marks says:

    Great post. I couldn’t agree more. You are *always* wrong. Except about the fact that you’ve just admitted you’re always wrong. Bit of a paradox that. Maybe you’re always right and I’m always wrong after all.

  2. If you’re a glass-half-full type of person, you could also label it as “you’re always just right enough”.

    But indeed: one of the hardest things for most people new to agile is accepting that they have to release their work before they feel it is complete.

    What’s the saying again? Perfect is the enemy of “good enough”?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

My tweets

Other stuff

%d bloggers like this: