When do you need performance?

When you create a minimal viable product you also struggle with a paradox: How much performance is just enough to get traction? D​uring the MVP phase you usually don’t have to worry about performance at all. However, this is not always the case. Sometimes your MVP needs to attract more users than usual. This could be because the idea is ahead of its time, because you are not developing in a ‘hot’ industry, or simply because you are not the best at selling your idea so you need to show even more traction than normally needed.

Angels ­> Users ­> Features ­> Performance

The road between MVP ​and Feature Complete​ is a tricky one. You need to be able to have enough performance to avoid disappointing users, while avoiding big costs because you are operating at a loss. This makes good business sense because any money that you save could be put into more features, marketing, or other MVPs.

When bridging the gap between initial funding and angel investment, you are also bridging the gap between early adopters and the early majority. The amount of early majority users you expect will be the amount that you will need to support, performance wise. The catch here is your early majority will not tolerate performance problems as well as your early adopters did, but they will be the first ones to put a strain on your system. While this is happening, you will typically be also bridging the gap between MVP and Feature Complete which will increase the amount of features that put a strain on the system. Some angels want to see a larger amount of traction before investing. Since traction requires users, which requires features, you are forced to be wary of performance. A performance rewrite may cost money that the angels haven’t given you yet. These three chicken and egg scenarios are the performance paradox​.

Certain Application Types ­> Early Performance Needs

There are certain kinds of software problems that lend themselves to total failure. This is because when they arrive at the performance paradox, the answer is to do a complete rewrite.

Here is an example of the kinds of software that need to be completely rewritten if done in a hurried fashion by the average developer:

1) Anything requiring a social graph

  • Action based on friends of friends

2) Collaborative applications

  • Real time communication
  • Real time updates between users

3) Analytics

  • Leaderboards
  • Real time analytic updates

4) Anything chatty

  • Anything requiring a social graph

If you are within any of these fields of software you need to either overbuild the application or be prepared to rewrite your application from scratch during the early majority phase. If you do not, you will not be able to handle the user load.

When considering the problem assessing performance, It is helpful to contrast the following two maxims of software:

“The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil​(or at least most of it) in programming.” ­ Donald Knuth


“There are three great virtues of a programmer; Laziness, Impatience and Hubris.​” ­ Larry Wall

Which leads us to the following synthesis qua performance paradox:

While premature optimization is the root of all evil, it is developer hubris that allows late optimization to be taken with a grain of salt.

A good question to ask your development team is: “How many hits per second can we support?” This is not the same thing as asking “How many users can we support?”. You need to have the hits per second number to survive performance problems. Another good question to know the answer to is “What kind of performance testing did we do to support that number?”

Grigorik, Ilya states:

‘… studies have shown that most of us will reliably report perceptible “lag” once a delay of over 100– 200 milliseconds is introduced into the system. Once the 300 millisecond delay threshold is exceeded, the interaction is often reported as “sluggish,” and at the 1,000 milliseconds (1 second) barrier, many users have already performed a mental context switch while waiting for the response — anything from a daydream to thinking about the next urgent task.’

If your performance tests yield results that are slower than 1,000 milliseconds, you should address the problem.

Difficult Performance Problems ­> Executive Level

In the end, performance is an executive level responsibility. Whoever is performing the role of CTO will need to make the tough decisions to address the performance paradox. Knowing the pitfalls and where they pop up goes a long way towards mitigating the problem. Knowing the right questions can forestall programmer hubris. The CTO should pay special attention to the bridging the gaps between MVP/Feature Complete, Early Adopter/Early Majority, and Self Funding/Angel Funding as this is when performance paradox occurs and is normally the most sensitive. Lastly, choosing the right performance architecture can be the difference between success and failure.

To find out how much your business can benefit from a performance boost, contact VULK at 1.512.788.5434 or visit http://www.vulk.coop for a free analysis.

Special thanks to Krista Williams and the Vulk team

Copyright © 2016 W. Watson, Vulk LLC 
 All Rights Reserved

Originally published at blog.vulk.coop on August 5, 2016.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.