“If you’re really good at software performance engineering you’re only wrong about 95% of the time”

0. Refer to you whatever-it-is as your latest crazy idea.

I know this has nothing to do with anything, but it will help you to get in the right frame of mind. Be suspicious of yourself. When discussing with others don’t sound like you’re committed to this one approach. As you collaborate let others refine and reject some or all of your crazy idea. If you’re good, your crazy idea will mutate (in maybe 20 steps) into an actually-not-that-crazy idea. Don’t worry, nobody will remember the earliest and craziest forms and you don’t have to document them unless you think they have value for humor or education.

1. “Does this crazy idea even work at all?” — try it out on the dumb

As soon as possible try out your crazy idea. Find the stupidest experiment you can do that gives you evidence that this crazy thing actually might be useful. The key is KISS.

2. “What could we possibly save?” — get a number, or numbers

Now that you have some prototype that shows that this crazy idea has a hope of working, let’s do a measurement. The job now is to build something on the cheap that gives you an idea what you could possibly save in your wildest dreams. Note: the code doesn’t have to really work at this point, in fact it usually won’t! The point here is not to get it fully working but to just try things out and see what we’re even talking about.

3. “What could possibly go wrong?” — make a list

Another favorite aphorism of mine is “It’s easy to make the code fast if it doesn’t have to work.” Now add this one “Performance improvements that add a lot of complexity are rarely a good idea”. With these two notions you have powerful guidance.

4. “How do we try this out?” — make a plan

If you’ve gotten this far your idea probably looks only vaguely like it originally did. You now have a simpler approach that has a chance of working. The next thing you want to do is start making a plan of baby steps to take towards making this real. If this were a battle this is the part where you figure out what weapons you need and how you will get them and use them. There is still no “fighting”.

5. “Can we code yet?” — start working and be careful

By now you have a good idea what wins you are expecting and how you’re going to get them. You can start doing the work in an orderly fashion while verifying that things are going as you expect. Do not ever make the mistake of saying you will have no way to know if your crazy idea is any good until you’re finished — that’s lame. There should be clear signs that things are going swimmingly at each new stage of development. Some are indirect, that’s ok. Some are only lab measurements, that’s ok. No checks along the way is not ok.

  • the wins you’re seeing in the real code are in the same ballpark as the early dumb tests
  • the ideas you had for maintaining correctness and simplicity are working as intended
  • the tests you added for the same are passing
  • no new significant problems are popping up that are making you re-think the whole idea

6. “How did we do?” — time to test the pudding

At the end of the day, you get the win, or you don’t; but by the time you’re at this stage you really are unlikely to be surprised. Most things that could go wrong were ruled out far earlier. We of course still do get final results because this is where we find out how good our projections were. If we’re wrong at this point, it won’t be the most economical lesson, but there will still be things to learn.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Rico Mariani

Rico Mariani

I’m a software engineer at Facebook; I specialize in software performance engineering and programming tools generally. I survived Microsoft from 1988 to 2017.