POST DIRECTORY
Category business of software

After giving the prototyping mindset talk, I got repeated feedback that using the term ‘prototype’ had negative connotations. There were two distinct beliefs that I encountered.

  1. Prototypes are inferior, incomplete and aren’t suitable for the rigors of production use.
  2. Prototypes are thrown away once we are done with them.

Before we explore these beliefs, allow me to clarify what we mean by a prototype. Indeed, I’ve heard people refer to many different things as prototypes, and who’s to say their wrong? Here is the definition we use:

Prototypes are a stripped-down and minimal version of a product built to test a concept.

With this definition, it seems plausible that both of these beliefs could be true. However, in the world of software, prototypes don’t have the same constraints that physical prototypes do. Let’s dig into both of these beliefs further.

Belief 1: Prototypes aren’t for production

Software prototypes do not include all the features or safeguards you would expect from a production-grade application. We take short-cuts or fake aspects of the application. Other parts will not be hardened or will cover all potential edge cases that may be encountered.

The team will continue to iterate on a prototype until it works well early on for a small feature set. This initial prototype should be close to reflecting your MVP and will be quite valuable to users.

Even though the product may work well for a small group of users, imperfections in the product will begin to show as demand increases.

Working code goes to production

The one pattern I’ve seen repeated over and over again on software projects is that once an app works, it goes to production, warts and all. The product owners care more about a working application and are not concerned with how clean or well-refactored code. They don’t care about the short-cuts unless it directly hurts the business. Thus, if the product works for the business, that trumps the concerns of the developer.

There’s a common sentiment among developers that our mistakes and short-cuts borne out of the rapid prototyping process will stay at the core of the product for years to come. This is why some developers resist taking short-cuts in the beginning as they don’t want to have to deal with supporting their deficiencies or take the blame for when they eventually have issues in production. It even leads to over-engineering in the early stages of a product as developers are frequently convinced that if they have an imperfect prototype later, it will haunt them. The problem is until the business is proven, perfect code is wasteful and unnecessary.

If your prototype works, it’s going to production and it’ll stay there. The business would rather build on top of it than stop to rebuild it. Thus, it’s in your best interest to give your prototypes a solid foundation that can evolve over time.

Belief 2: Prototypes are thrown away

For physical prototypes, this is true. Sometimes it’s true on software projects where the team is explicitly doing a prototype that will be thrown away. Based on what we’ve already covered, I’ve seen this as the exception. Once a prototype works, the pressure to go live with it is too great to throw it away.

Given that we can evolve our prototypes over time, it’s not a requirement to throw them away. Then, a different question comes to mind…

When do you throw away your prototype?

The purpose of a prototype is to experiment and learn about your customers, your market or what’s technically feasible. With each experiment, we either validate or invalidate the assumption we are focusing on. When assumptions aren’t validated, we typically adjust the prototype to further test that assumption. This continues until you end up so far from your product’s initial vision that you need to make a large change, often to your product strategy. This is commonly called a pivot. You try to take some of what you’ve proven and shift from there.

Once we pivot, the prototype might be far enough from where the pivot is heading that we end up throwing away much of the code. We do this when it’s easier and more cost-effective to start fresh than modify what we built.

It might also be that you only throw away one part of your prototype. It all comes down to how much churn the design of the application has experienced.

Building prototypes to last

You can build a prototype flexible enough that you can backfill the missing parts or enhance immature implementations so they can handle the rigors of production usage. When it’s time to evolve your prototype for production, edge cases can be handled properly. All this is typically done at a fraction of the cost of rebuilding the entire application.

This is possible due to the malleable nature of software design. Unlike physical prototypes, with solid design principles, you can easily upgrade inferior components in an application when the time is right.

Boundaries and components

You can use your vision for how your prototype will grow into a full-fledged product to define boundaries of the different parts of a system’s design. The goal is to isolate changes in one part of the system from another so that they can be upgraded or replaced without forcing the entire system to change.

You can think of this approach as making small, composable components that work together to comprise the entire system. We strive to keep them as decoupled as possible so that changes in one component triggers a minimal change outside its component. One of the rules of thumb is that each component should be able to be rewritten in a week by a single developer.

As a matter of fact, we prefer to design small components that interact with each other in a simple way for all applications, not just prototypes. Even in mature products, things will change over time and you might realize that some component is inadequate to the changing business needs. This approach allows us to isolate that component and make a minimal change to the entire system. We can even rewrite the entire component from scratch without breaking the rest of the system.

This approach allows us to comfortably start with a prototype, knowing that we have a strategy to evolve the system at any point without throwing the entire prototype away.

Armed with these approaches, we expect that that initial prototype will be the foundation of your product. We can construct the application in a way so that you aren’t forced to start over once you’ve learned what you needed from the prototype. There’s no need to throw away your prototype!

''