The Dangers, and Benefits, of Software Fidelity

Cost is a fundamental constraint of all software projects. Engineering software is a complex practice, full of rabbit trails and unexpected twists and turns. Agile methodologies guide us through these precarious situations by embracing the reality that they will happen — keeping us on our toes. This keeps timing and costs visible at all times, so that we make smart decisions in the face of uncertainty.

When finding ways to lower the cost of development, there are two common considerations that teams make:

• Can we ship fewer features without compromising on the core business value?
• Can we be more efficient with the time we have?

While both of these considerations are critical, we’ve found a third which is just as meaningful, if not more so. Fidelity.

I define fidelity as the level of polish and preparedness of a software product. Newer projects with fewer users tend to be lower fidelity, while mature products with many users tend to be higher fidelity.

Commonly, fidelity manifests itself in these ways:

• Highly polished graphical designs;
• Interactive user interfaces;
• Products which are highly usable based on user testing;
• Supports more runtime environments;
• Scalability and stability.

In terms of building a successful long term business around your product, fidelity can make a huge difference. When we talk about an application being “a cut above the rest” we’re talking about one which is of higher fidelity.

Building in high fidelity too soon is risky. High fidelity products take longer to build, are more arduous to maintain, and react slower to customer feedback.

With this in mind, there are benefits to both low and high fidelity applications, and understanding your intended outcome can help you make an informed decision.

Consider the proverbial “back of the napkin sketch” of a new product. This is perhaps as low fidelity as you can be. It’s disposable. There aren’t any proven ideas about it yet. It’s all just a theory that needs to be tested.

Napkins drawings are also cheap and fast. We can sketch new variations of that product in seconds. It’s more about vetting the idea than it is about taking it to market.

The same is true of software development. Low fidelity applications can react and change quickly. These products involve fewer lines of code and less time in design, they have fewer fault lines and tend to break mainly in expected ways.

By deciding to be low fidelity, we are embracing changes that we can’t yet see, and therefore keeping costs low while we validate the product and how people will use it.

In the startup world, ultra-low fidelity concepts are referred to as MVP, or Minimally Viable Products. These startup companies are often ridiculously cash constrained, and so need to prove out their idea for only a few thousand dollars, before raising hundreds of thousands of dollars to build one to take to market.

High fidelity products are for time tested, stable products. Once you are confident in the direction of a product, a high fidelity product will be more attractive to customers and create better experiences which they will share with their friends.

One of my favorite examples of high fidelity designs are those created by Square, a merchant services software company run by Jack Dorsey of Twitter fame. Square's products are refreshingly sparse of features. They care deeply about finding only the essential features and creating the highest fidelity products possible. They are exceptionally usable, graphically polished, and hugely scalable.

As a way of addressing this productively with our clients, we coined the term Progressive Fidelity. Simply put, progressive fidelity is a method for starting with a lower fidelity product, then over time growing the most important features into higher fidelity as we test and verify at each stage.

Here’s how we do it:

1. Start with sketches. Whiteboard, paper or simple digital sketches are fast, loose and disposable.
2. Turn your sketches into a clickable prototype using a tool like Invision. This brings the fidelity up a tiny notch and allows us to feel the application in action.
3. Architect the technology. Design a solid application framework that will develop this prototype into a functional application.
4. Design more polished proofs of the key application screens. This helps visualize what the product will look like at it’s first release.
5. Build version 1. Take our low fidelity application concept and turn it into a fully functional, low fidelity application.

These 5 steps are collectively called a “Release.” That is, a publicly available launch of the product. Each future release of the product follows these same 5 steps. As a result, periodic releases continually improve the product adding new functionality and raising the fidelity.

Even if you have the money, it’s not smart to buy a Ferrari as your first car. Those are expensive cars to drive, and aren’t ideal for learning. Start with a Honda Civic, and move up as you get more confident.