2024 Public Training Schedule
November 18 – 21, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
December 9 – 12, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- September 29, 2010 ( 1 comments )
- Rants
Sometimes I hear developers say that they are scared to build prototypes because their manager will make them ship it as a product. There is a big difference between a prototype and a product. A home builder wouldn’t mock up a house out of cardboard and then try to sell it so people could move in even though it might hold up on a dry summer’s night.
Prototypes help us understand what a product will be like or we can use them as a proof of concept to validate some of our assumptions about what we are building. But a prototype is not a product because it does not have the robustness or supportability of a product yet.
It is fine to take shortcuts when building a prototype. The purpose of a prototype is to elicit feedback from others or verify a design approach will work. When doing this we generally only concern ourselves with the “happy path” through our code. This is ok as long as we later go back and handle the error cases we missed.
Prototypes can also be sloppy. When we are trying out ideas that we aren’t sure are going to fly we may not have the most intention revealing names for our methods. The process of turning a prototype into a product should focus on making the code more robust and more supportable.
There is a very different mindset we use when building a prototype verses building a product. Prototypes can be quick and dirty; products must be robust. When we don’t pay attention to the productizing phase of development we end up driving the cost of ownership up significantly for the software we build.
{1 Comments }
Previous Post: « To Be Agile (Techniques of Design) now offers Certified Scrum Developer training!
Next Post: Prototyping Caveat »
That is one way to think of it. But a prototype does not have supportability so it must be hardened so it will be cost-effective to support in the field.