Monthly Archives: June 2008

More on Prototyping

To convert the unknowns into knowns, you need to aggressively prototype.

What to Prototype?

Here are some examples:

Prototype the use of an API. Create a prototype to see if the API that you need to use works the way you think it does. This includes confirming that it can be called with parameters of the type and range that you can provide. The API may belong to a component that one of your team mates wrote, or it may belong to a third party library. Either way, you want to be absolutely certain about how to use it. No amount of documentation reading will substitute for a well pointed prototype.

Prototype an algorithm. Create a prototype to prove to yourself beyond reasonable doubt that you can implement the solution to a problem.

Prototype an interaction. Create a prototype to show that the interaction sequence or method that you want to use in your application actually works for the intended use. You can take the prototype and usability test it, incorporate the feedback, and then place it into your application.

What should the prototype look like?

Since we are talking about software development, your prototype should be a software program. A small program. As small as possible. A program that answers one or two critical questions and that’s it.

The prototype should be like the small program that you write to prove to the API writers that their API has a defect. It has to be small and prove one point. Your objective from the prototype to learn something that you didn’t know, or confirm something that you suspected.

How to Prototype?

Pick one or two key questions that you want your prototype to answer and focus your small program answer them. Keep in mind common software engineering and experimentation principles as you decide on how to proceed:

  1. divide & conquer: write multiple prototypes as needed
  2. reduce scope: keep the scope of each prototype to a minimum
  3. isolate concerns: separate the concerns so that you can establish root cause
  4. confirm behavior: confirm that an API behaves exactly the way you had thought that it would under the conditions that you anticipate
  5. validate assumptions: validate that what you think is true, it is indeed so
  6. validate invariants, pre- and post-conditions: half the battle is to identify these; you get extra credit for validating them

I have noticed that after a while some prototypes that started out with the best of intentions, become monsters. Don’t be tempted to stick another one or two topics into an existing prototype. Your prototype will become so complicated that you cannot confirm root causes for outcomes. Then you lost your ability to know things for sure.

Lastly: the most important rule is a well worn one: KISS=Keep It Simple & Sufficient.

Why Prototype?

Every once in a while I am surprised by somebody who says that prototyping is such a waste of time. For quite some time I have taken for granted that prototyping is a fact of my software engineering life. Maybe it is worth asking: what is the problem for which prototyping is the answer? Or, in other words: why should you prototype?

You should prototype when you don’t know enough about about the problem. Which is almost always. When your knowledge is lacking in some aspect, then it is time to write a prototype. When you don’t know enough about an API, some requirement, the operating system that you are designing for, the libraries that you want to use, and so on. When you feel that you have to answer a few clarifying questions, then it is time to answer them with a prototype.

The short answer is that you prototype because you don’t know enough to proceed with the project at an acceptable level of risk.

Version Numbers and Component-Based Software Development

Component-Based Software Development is a topic I return to from time to time. It is almost ancient history now: it was in 1993 when Microsoft came out with OLE (Object Linking and Embedding). OLE was based on a simple premise: a component can ask another component a simple question: “Do you support interface X?”

Let’s suppose that component A wants to use component B. Component A can ask Component B if it supports any of the interfaces that A needs. The process is to ask B for each interface, specifically for each version of each interface that A can use. If B supports one, then they can work together. If B doesn’t, then A has to look for another component that supports what A needs.

As already noted, B has to support the version of the interface that A can work with. Interface versioning and the proper assignment of version numbers is critical to make component-based software development work.