reflective software development, as a service

Menu

go ugly early

I don’t think I had heard the phrase “going ugly” until I read Go Ugly Early by Dwayne Melancon today. To quote Dwayne:

“This concept involves releasing early iterations of your products so you can allow your customers to interact with them and provide feedback. I’m not talking about releasing unstable or buggy products – I’m talking about releasing stable products that have limited functionality, but which telegraph the shapes of things to come.”

Which, of course, is exactly the approach promoted by all of the agile software development methods. Sort of.

In fact, the agile community has amazingly little to say about beta programmes and the like. We talk a great deal about the OnsiteCustomer (aka ProductOwner or ChiefEngineer or ProductDirector) who gives rapid feedback to the developers on a daily basis. But that’s not the same as giving a try-out version to a few key users. If you’re developing something you would use yourself, then trying out your own dog food early is very easy and relatively risk-free. But when the target user is potentially a paying customer, it can be all too easy to perceive the risks as outweighing the advantages. What if they laugh at our half-baked ideas? What if they steal the idea and take it to our leading competitor? Frankly, I don’t believe any of these are real issues. Not compared to the benefits of using early-access free stuff to forge a long-term relationship.

The ProductDirector’s rapid feedback and direction is essential in the microcosm of the development shop itself. But in addition, giving genuine users the chance to genuinely use parts of your new product under genuine conditions can be … genuinely useful – both to you and to them. Your user (or potential user) is being given the opportunity to ensure that your next product fits them like a glove. Most will be prepared to invest a little time to get that. And if they laugh, you’ve learned something about your understanding of the market – and you’ve learned it without investing the whole kaboodle.

Of course, the partial system must be production quality. If it isn’t bug-free and trivial to install you will probably be dismissed out of hand. (Again you’ve learned something – but it was something you already knew and could have avoided.) So this isn’t prototyping, it is real product development, in small chunks. The opportunity only arises because of honest and thorough use of agile practices such as TDD, ContinuousIntegration, DailyBuild etc. (Maybe that’s where the perceived risks come from: this is all new. Waterfalling never gave us the chance to create this kind of relationship with our customers.)

Do you have a story where going ugly early saved your bacon? I’d love to hear it.