Before I tick off another TechReady day, I will continue our SDLC discussion threads from SDLC – Software Development Lifecycle … agility strikes back with energy (part 4 of many), with a quick focus on prototyping.
When we are faced with assumptions, uncertainties, choice, evolutionary analysis and development or the need to test ideas, we often call the software prototyping to the rescue. While I personally support and love prototyping, I am probably also the biggest critic and sceptic … if used correctly, the prototyping arsenal is truly powerful, but if it steps over to the dark side, it can be just as destructive.
What is prototyping?
There are many definitions on the internet and in people’s minds, but in essence we can define it as: “A working and incremental model of a projected throw-away solution, constructed, tested and evaluated rapidly.”
It is said that the biggest justification for prototyping is to reduce uncertainty by conducting experiments … was(is) Skynet not an experiment as well?
So why should we even consider prototyping?
The reasons I support and actively promote prototyping is the ability to clarify things such as technology choices and concepts, to validate requirements and designs, to demonstrate ideas and understanding of the problem domain to all stakeholders, to improve and motivate collaboration amongst all solution stakeholder and to enable learning by doing experiments and validations early on and through-out the process of s software solution.
What are the dark side droids we need to keep an eye out for?
How many of us have worked on throw-away prototypes that end up in production? Last time I checked a CTOS (Convergent Technologies OS … long gone!) based prototype I was involved in during the late 80’s was still humming along in production environments … it was a prototype to demonstrate a concept and evaluate technology.
A prototype should always be seen as a throw-away product by default. If not, then different quality and process restrictions apply … at which point I personally question whether we should not regard it as a project, rather than a prototype … but the jury is obviously still out debating this topic.
What are some of the pitfalls of solution prototyping we should be aware of?
The dark side includes the potential for misunderstanding when intent and scope are ill defined. How does a user testing a piece of solution know he is working with a throw-away, which may lack error checking and performance, or why should he not expect to be able to use what he is testing, if it meets the business requirements? The risk of lack-of-quality is high, as prototypes are often hacked out to try out ideas and technologies, with no support for production strength stability, scalability and performance. The minefield of cost is also a substantial concern, because a throw-away prototype is going to cost more and most solution sponsors do not appreciate us throwing away their perceived investment … intent, scope and clarity is essential to address this concern. The other side of the coin is the potential cost associated with maintaining a prototype in production … I am sure I am not the only one who notices prototype smells in solutions and source code. If a maintenance developer opens a mission-critical solution black-box, the last thing he wants to encounter is prototype smell.
|Which of the two bridges likely represent a prototyped solution? || |
You have reason to be concerned, when you hear the following questions or statements, or parts thereof, in secretive sessions in the hallways:
- You like the ‘release’? Yes, we could consider …
- We have run out of time and budget, let’s just …
- Let’s deploy the prototype to pre-production, …
- Let’s cleanup the prototype and use it for …
- Let’s use the prototype in production ‘as is’, until …
- Do not mention to anyone that we are working on a prototype …
- The prototype will be a solid foundation and/or framework for the solution …
- Let’s ship the prototype and cleanup over time …
|… that’s normally when it is time to … || |
TFS|VSTS … valuable in this environments?
Absolutely, especially when considering the new Visual Studio 2010 features which are supporting test driven development. More on this when the VSTS 2010 BETA ships.
So, is software prototyping good, bad or evil? Typical IT answer … it depends! It is a powerful solution approach and can be invaluable to the overall success of a solution if used with care and in the right scope. Set the objectives, the scope and the limitations of prototypes early in the project, do not compromise on agreed scope and quality and you should find prototyping an invaluable ally in your arsenal of software engineering arsenal.
When you enter the passenger plane on your next journey, have a look at the labels on the main door … perhaps you will notice a reference to experimentation or prototyping … should make you think whether prototypes should be throw-away or possible candidates for mission critical foundation or framework solutions.