Lean CFD

A little background…

I’m a really bad procrastinator. I’d much rather research 5 ways of doing something and read 3 books on a subject than just get on with it. I’d like to think that if I’ve done my homework then I’m less likely to make the wrong decision. The upshot is that, decisions go unmade for too long and I learn loads of stuff that I don’t need to know. Maybe it’s just that if I can put it off for long enough then it might disappear and I’ll never actually have to do it? Usually I just slam up against a deadline and don’t actually have the time to procrastinate any more. I should take a leaf out of Bill Murray’s book…

“If nobody comes from the future to stop you, how bad can the decision really be?”

— Bill Murray

You might be thinking “that’s a nice personal insight, but what has it got to do with anything?” – I’m getting to that. When I was setting up CFD Engine I read The Lean Startup by Eric Ries (amongst countless other books). Unsurprisingly, I didn’t really follow it but some of it really resonated with my background in aerodynamic development and changed the way I do my CFD analysis.

One of the key aspects of Lean is the Build-Measure-Learn feedback loop. This involves making a hypothesis about some small aspect of your business. Building the minimum thing required to test that hypothesis. Proving (or disproving) it. Then using that lesson to inform your next hypothesis. It’s not a new management concept, kids do it all the time – like validating their hypothesis that an M&M will fit up their nose. And then looping through again to test whether they can get it out without involving emergency medicine.

The subtle bit of the Build-Measure-Learn loop is figuring out what to hypothesise about and only using the minimum resources necessary to figure out whether you were right.

What question to ask?

Honestly, the initial hypothesis isn’t really that important. What’s more important is that you cycle it through a why loop. If you have small kids (or have friends with small kids) then channel your inner 3 year-old and develop your own “Why?” reflex. After stating your latest product development idea, repeatedly ask “Why?” until you get to one of your key metrics. Sometimes, it only takes once through the loop. But if you can’t get from your latest idea to one of your key metrics by asking “Why?” 4 or so times, then it’s probably not the thing to be focussing on right now.

Hopefully, you’ve got a pretty solid development metric for your product? If not you can use the same “Why? loop” to get to a meaningful metric if yours is a bit lightweight.

Minimum Viable Model

Your hypotheses are supposed to be small bets that won’t break the bank if they don’t come off. Low risk, just in case they don’t work. Sometimes this also means low reward. In that case you’re going to need to cycle through the build-measure-learn loop quickly. Then compound these small gains into something meaningful.

This is the opposite of a science project where you make one humongous hypothesis, bet the house on it and spend all your time & budget trying to get some evidence to support it.

You need the minimum viable model required to prove your hypothesis. This applies to cell counts, physics models and the level of detail in the geometry. All of which can quickly spiral out of control and end up eating your time and money before you’ve made any progress. Emphasis is on both adjectives, both are equally important.

• minimum — no more than required;
• viable — capable of answering your question;

If your minimum viable model (MVM) is a 1D model in Excel then great. But, if your hypothesis needs multi-billion cells and a month on Titan to test it, then you’re probably thinking too big.

How does this affect how we work?

This approach crops up all over the place when I’m consulting.

It crops up in initial meetings. I ask a lot of questions, effectively running through a why loop, to get to the real reason you want to do CFD. Or why you want to make a particular model change. Or why you want to develop a new product. It borders on business coaching or even intrusive. I don’t want to do work that has no chance of meeting your goals because we never really got to discuss your true goal.

It crops up when I’m building models. Do we really need to model thermal properties at this stage? What will we gain by adding another ride-height? Are we in danger of producing more data than we can make sense of? Do we need to model all the nuts and bolts at this stage?

It crops up when choosing what hardware to run on. What is the minimum viable machine I can put this on? What impact would reducing the run time have? Can I reduce the cost without affecting the outcome?

It crops up when I’m analysing data. How can I tell the story of this design change without just throwing-up all the available data into the customers lap? What are the actionable nuggets that I can promote? What is the next step towards the end goal?

For me, Lean is all about doing the most you can with the least possible waste. So whilst it was really intended as a guide for venture-backed start-ups, it’s been pretty useful for me. As a solo operator I don’t have anything to waste, so being as efficient as possible is a necessity. Plus it gives me more time to spend on reading about how to be more productive ;-)