Dak design trade-offs

Design trade-offs, and the virtue of fast (part 3 of 3)

So, what’s the lesson for software in these different examples of “the high end” vs. “the cheap”?

In my view:

1) Make a cheap (FAST) prototype. It may not have the cachet of the ultimate product, but it will validate the functionality of the product, and begin the incremental test/design/improve cycle.

2) If you have a high end product, make a cheap prototype of what might displace you. It will generate new ideas; the cheap prototype may not be something you can sell or make a profit on, but you will at least know where to look for a potentially disruptive competitor. Keep incrementing the cheap prototype; it’s better to disrupt yourself than for a competitor to do it, and your time as the only ‘cool thing’ in your category will end eventually. Moreover, your high-end product needs to pay for development, and is, in any case, a ticking time bomb waiting for someone (you? a competitor?) to destroy its value.

Note that Steadicam has done this; they have their high-end product, and have introduced their low-end product, but have shunned the “too cheap to make a profit on” product.

(If you’ve read The Innovator’s Dilemma you should be nodding your head at this point. If you haven’t read it, you should.)

3) Huge development costs for high-end products are risky. They need to be amortized quickly and/or defended vigorously. They can serve as a barrier to entry for your market…but you have to beware the lower-cost entrants!

To me, this is a compelling reason for incremental software development. Get the requirements, build a prototype, increment until good enough to field. Repeat cycle. Keep it fast; software development tools and training are much better than they were, say, 15 years ago. Even if you don’t release the prototype to the customer, build it this way *anyhow*.

What if you’ve got a big legacy system? The same lessons apply: build extensions incrementally, and by writing the tests first, and the code later. Think about prototyping replacements to the legacy monsters, even if you have to do it piece by piece. (Building tests for those legacy monsters is a great way to get started on replacing them; how else are you going to know if what you’ve built is backwards compatible?)

Comments, as always, are more than welcome.



Design trade-offs, and the virtue of cheap (part 2 of 3)

Another data point (for delivery over the web).

This is a Vlog of an interview of fixed gear bike rider. (Thanks to Bruce Sharpe for twittering this one).

High end gear vs. the “flip video” camcorder (not a lot more than $100).

Good Enough not to distract from the task at hand. There’s a lesson here (a whole flock of them, really). What do you think it is?