11: Build the right kind of prototype

Umm... sure?
Tracer bullet?
Walking Skeleton?

I don't know where this one is really going. As a practitioner of Emergent Design and Evolutionary Architecture... I'll just start coding and refactor the hell out of the system as I go. Practically always functional, definitely always deployable. It's a good form of 'prototype into production'. Though, even this way, don't prototype into production. Prototypes need to self destruct.

"There are two types of prototypes: throwaway and evolutionary". Nice first sentence, I fully agree.

Throwaways are hackjobs; evolutionary are done w/quality, but quickly.

I think anytime you use a throwaway you could use an evolutionary; except in the case of mockups. There's no good way to build a mockup in an evolutionary fashion.
I've done them; it's more of a throwaway in an evolutionary framework.

The books distinguishes on the developers understanding of requirements. Poorly understood are throwaways for getting enough information to well understand the problem. Well understood are evolutionary to ... evolve... through user feedback.

The throwaways should be developed in a fashion that bakes in assumptions for areas we know well. Hard coding a lot of the details we don't need.
Example - If we need to ensure military base addresses outside the US work - hard code values in a drop down and have the entire page client side. Fake network/disk/database. Lots of hard coded hacks to get enough information to reduce the unknown.

Yeah... I pretty much agree with this one. I do like to do "throw away" inside the evolutionary if possible. It provides the users a VERY real experience, with the unknown functionality hacked in. I've done this with how to best display things - All hard coded. How to collapse and expand based on quanitity in the list. Couple hard coded tabs showing options. Once we understand it better, and have some user feedback; start to implement and continue to refine with feedback. I like to keep the data faked for a long while; and even keep a couple UIs to toggle between (with different situations) to make sure all scenarios behave as expected.

But yea... a solid Principle as described in the book. This is 4 out of 11? Something terribly low... Go go gadget blog fodder!!!