I originally wrote this for the Trust IV blog, but I thought it deserved a “republish” here…
As a performance tester, along with many people in the IT-world, I’m often asked to plan for different eventualities. I have to write test plans, software deployment plans or help to provide estimates for how long a piece of work will take. For predictable, simple work, this is fairly easy and is the sort of thing that people learn in school maths lessons. e.g. “If it takes one man one hour to dig a hole, how long will it take two men to dig a similar hole?”
In the IT world it often isn’t as simple as that. To (mis)quote Donald Rumsfeld, things that catch us out are the “unknown unknowns, those things that we don’t know that we don’t know.” How can we be sure that the configuration of a particular server is the same as the last one where we performed a particular task?
How do we know that the test data that we’ve been given is a true representation of live data?
How can we be sure that the business requirements we’ve been given are correct?
With a whole host of unknowns we need to be prepared to change our plans at a moment’s notice.
This is where the “dead Prussian” comes in…..
This c
hap is Helmut von Moltke the Elder; a Prussian army officer who died in Berlin in 1891. He was the chief of staff of the Prussian army and an excellent strategist. Rather than directing his armies with explicit commands, which ran the risk of becoming irrelevant quickly, he recognised that it made more sense to describe an overall strategic plan to his officers and rely on them to help him to achieve his objectives.
He recognised that military strategy was best described as a system of “options” since only the beginning of a military operation was plannable. He tasked his officers with calculating numerous possible outcomes and “what if?” scenarios. Only by preparing for multiple possibilities, could he be ensured of success.
His ethos is best described with the quote which is most commonly attributed to him:
“No plan of operations extends with certainty beyond the first encounter with the enemy’s main strength.”
Often abbreviated to:
“No plan survives contact with the enemy.”
I think that “Moltke” would have been at home in the IT world. He rejected a single detailed plan in favour of multiple “what if” plans and empowered his subordinates, trusting them to make the right decisions, despite the fact that he couldn’t always be in contact with them. Although the “military subject matter” of his famous quotes isn’t pertinent in IT, the theme remains relevant.
As I tester, I believe that these quotes are spot on:
- No test plan survives first contact with application code.
- No project plan extends with certainty beyond the first milestone.
- There is no such thing as the “perfect test”, prepare for the unexpected.
- If something can go wrong, it probably will….. be prepared for it.
Can you think of any other “Moltke-themed” quotations that are relevant to you?
Answers on a postcard….well perhaps in a Tweet to @TrustIV or @RichardBishop
G’day mate.
You seem to post random ramblings and also little tips in your field of expertise performance testing. Like myself 🙂 but on the other side of the planet in Australia. Your post about a dead Prussian and your comments about the practicality of test plans are true but its what the money changers want.
I often say to people in my industry, that our field was invented by a Dane that was born in 1878. Now that i read your ramblings maybe you can consider mine that no one listens to.
https://en.wikipedia.org/wiki/Agner_Krarup_Erlang
http://www.mitan.co.uk/erlang/elgcmath.htm
http://www.mitan.co.uk/erlang/elgcspsh.htm
https://en.wikipedia.org/wiki/Erlang_(unit)
Hi Scott,
Thanks for yor reply. I read the atricles that you shared about Erlang. I hadn’t heard of him until now, so it was good to read his theories and see how well they still apply to modern queing systems. I’ll definitely keep him in mind when I next need to describe queuing behaviour to a customer. Perhaps I should write a blog entitled “What a long dead Dane can teach us about IT”, it sounds like a theme could develop 🙂
All the best
Richard
You’re most welcome Richard
Simply put;
Erlang A = Is simply defining the Unit of measurement you want to measure
Erlang B = If my given level of capacity is X what is my ability to service my expected demand
Erlang C = If my expected demand is X what does my level of capacity need to be if i want to achieve a SLA of X
The formula was defined for portable mobile telecommunication networks in the 20th century. Due to its history in the telecommunication industry, it is the standard for reporting upon capacity and performance. A lot of call centres use it to measure their capacity to service expected demand.
I was leading a team of performance testers and our findings were disputed by the vendor who was a major telecommunication company. Everyone on his side of the table and including my own team on our side of the table was shocked when i argued him down using the their own mathematical formula. No one understood the conversation other than to perceive that the person that had tried to confuse everyone in the room by using technical terminology to prove how intelligent he was and we as mere software testers were bunch of idiots that did not understand the technology we were testing, came off second best when I asked him the finer points of his mathematical formula and asked what point was he actually trying to make? When I explained the formula back to him and showed that his own mathematics proved we were correct, he clearly only proved he did not understand himself what the hell he was talking about when he used this formula to try and big note himself, his only proof using this formula obviously thought it sounded pretty good in the past when he used it to win an argument but never actually understood his own argument. This one meeting has been the only meeting after doing this nearly 15 years, where this knowledge was actually was relevant. If you send myself an email, one day I will reply, I usually am busy, with a possible suggestion of a blog entry of why this guy is the father of performance testing. I actually came across you reading Stewart Moncrieff’s blog. Even though I do enjoy these blogs and do use them personally, I do see them as double sided sword that just helps others that I do not want to help particularly from one country. https://www.upwork.com/hire/loadrunner-freelancers/
So would rather the odd email here and there
I suspect this formula will get more and more relevant to our industry. Cyara no longer enjoys exclusively to itself, this 100 mill market of telecommunication performance testing. As VOIP is being integrated into Siebel and Sap to manage customer engagements. Also vendors deploying voice identification to speed up servicing (Barclays Bank in the UK) government agencies that want to enable law enforcement to identify people, our field is slowly being engaged as most the issues are in this integration of the technologies required.
http://www.verint.com/about/company-profile/
http://www.genesys.com/resources/Voice-Biometrics-general.pdf
http://data-synergy.com/products-and-services/#data-synergy-voice
This add in was written by Stan Gourevitch, the previous lead developer of load runner at Mercury (remember them ?) for 6 years…. You may have heard that this tool is now owned by the UK company Micro Focus that now owns QA Load, Silk Performer, Borland C, LoadRunner and… well too many to bloody list.
Enjoy reading these links that are far more relevant.
Also this is pretty cool
https://github.com/chorasimilarity/chemlambda-gui/blob/gh-pages/dynamic/README.md