Robust KISS
My father would remind me to KISS - Keep It Simple Stupid!
This often came up after I did something that wasn't simple but was stupid.
Dilbert's 9 rules for financial planning provide a great example of the KISS principle.
- Make a will.
- Pay off your credit cards.
- Get term life insurance if you have a family to support.
- Fund your 401(k) to the maximum.
- Fund your IRA to the maximum.
- Buy a house if you want to live in a house and you can afford it.
- Put six months’ expenses in a money market fund.
- Take whatever money is left over and invest 70% in a stock index fund and 30% in a bond fund through any discount broker and never touch it until retirement.
- If any of this confuses you, or you have something special going on
(retirement, college planning, tax issues) hire a fee-based financial
planner, not one who charges a percentage of your portfolio.
From Dilbert and the Way of the Weasel
These are simple rules that provide excellent guidance in a very complex field.
For 95% of the people in the country following these rules would improve their personal finances and would save in aggregate $100 of billions.
These rules may be the optimum strategy for only a fraction of us. I don't claim they are optimal for 95%. My claim is that for 95% of the population these rules will provide a better outcome compared to what they are actually doing today.
What lessons can we take from Dilbert's financial advice that will apply to growing a software venture?
A-list software ventures tend to be populated with smart driven type-A personalities. Who are capable of dealing with a high degree of complexity and who like to demonstrate that ability. People who often are more skilled at coming up with clever insights than they are at communicating simple actionable ideas. Many of these folks tend towards a paradoxical combination of perfectionism and a fire-fighting mentality. Which in turn leads to strategies/policies/plans that are either
A) truly baroque and complex in an effort to create fine-tuned optimization
OR
B) non-existent - replaced instead by reactive ad hoc behavior
With this context I see 3 key lessons from Dilbert's fine example of KISS in action.
1) Simple is better than none
Most people don't have a financial plan of any kind. Clearly following Dilbert's simple rules would make them much better off, even if it does not provide the best of all possible worlds.
Similarly, it is incredibly common for fast-growing software ventures to live without clearly stated and widely understood strategies, policies, and plans.
In some of these cases a few individuals have in their heads sophisticated ideas for how to address these needs. Ideas that don't translate easily to simple declarative statements that get immediately written down. The expectation seems to be that through example and osmosis these sophisticated ideas will transfer to the rest of the team.
In other cases, everyone is too busy reacting, firefighting, and addressing the 'obvious' urgent needs to bother writing down specific plans or practices.
In other cases, the desire to create a very elaborate and complete plan leads to a long planning cycle, so that many such cycles are started but none are every completed before they are interrupted. This is one reason why striving for a truly complete specification can be the wrong thing to do a simple spec that is up to date and conveys critical info is better than striving for a 'complete' spec and in effect living with none.
In all cases, it would be better to write down, clearly communicate, and then consistently live by some simple plan than to live without any at all.
2) Communication and execution matter more than cleverness and optimization
When it comes to personal finance many people do too much rather than too little. People tend to overestimate their ability to optimize their financial results through cleverness and activity. They tend to underestimate the value of simplicity, consistency, and low-costs. This is why almost everyone who actively trades stocks does worse than if they just paid credit cards and then invested in a cross section of index funds.
Similarly at software ventures we tend to use our cleverness to try and get the best possible results through creation of a complicated plan. We tend to underestimate the value of simplicity. Simple plans are easier to communicate, easier to execute, and easier to adjust as you get new data.
These benefits from simplicity apply both in business planning and to software design. The most elegant technical improvements often come when we innovate via simplification.
One clever person with an intricate vision of how all the pieces fit together, isn't enough to make a team succeed. Coming up with a simple approach that can be effectively communicated to everyone is a mark of true understanding.
As Pooh pointed out in the Tao of Pooh:
"Rabbit's clever," said Pooh thoughtfully.
"Yes,"said Piglet, "Rabbit's clever."
"And he has Brain."
"Yes," said Piglet, "Rabbit has Brain."
There was a long silence.
"I suppose," said Pooh, "that that's why he never understands anything."
Lots of folks at software ventures are like Rabbit. They show off their cleverness with intricate plans that they never get everyone to understand and that are impossible for mere mortals to execute. When what is really required to get an effective common understanding is simplicity.
3) Robustness matters
Of course not all simple plans are created equal. Simple by itself does not guarantee success. The plan needs to be simple and effective.
One measure of effectiveness is robustness. Wikipedia has a nice definition:
Robustness is the quality of being able to withstand stresses, pressures, or changes in procedure or circumstance. A system, organism or design may be said to be "robust" if it is capable of coping well with variations (sometimes unpredictable variations) in its operating environment with minimal damage, alteration or loss of functionality.
Dilbert's financial plan seems robust to me and that is a very good thing.
Simplicity often improves robustness, as it is easier for a simple system to adapt to changing circumstances.
However, it is possible to go too far. As we strive for simplicity in our software designs and business plans, we don't want to make a plan that will only work in our immediate circumstances. We want to create something that is "as simple as possible but no simpler" and one good measure of that is the likely robustness of that plan in the face of a changing environment.
copyright 2007 Kerry Champion
