Ricochet is the best place on the internet to discuss the issues of the day, either through commenting on posts or writing your own for our active and dynamic community in a fully moderated environment. In addition, the Ricochet Audio Network offers over 40 original podcasts with new episodes released every day.
Quote of the Day: Wrong and Dumb
“Step one should be to question the requirements,” he says. “Make them less wrong and dumb, because all requirements are somewhat wrong and dumb. And then delete, delete, delete.” —Elon Musk
I’m in the middle of the biography of Elon Musk, written by Walter Isaacson (and I will write a book review soon). But this statement of Musk’s made me laugh out loud, because it is not only representative of his determination not to be limited by rules and requirements, but he has proved over and over again that the requirements are often absurd, time-consuming and wasteful.
His comment reminded me of the story of the woman who, like her mother, would cut off the ends of a pot roast before cooking it. When she was asked why she did that, she realized that she didn’t know. When she finally asked her mother why she prepared the roast in that way, her mother told her: the roast was too large to fit in the pan otherwise!
How many activities in our lives are limited by our preconceptions, our erroneous understanding of the rules, our fears of doing the wrong thing? How many things do we choose not to do because they are unfamiliar or seem dangerous, unpopular or silly?
One of the most liberating actions I pursued many years ago was imitating one of our group leaders in a skit at a conference. I decided to go all out, having no idea how I would be received. I danced around the room, said outrageous things, teased people—the crowd roared, because they knew exactly who I was roleplaying. My beliefs about always trying to do the right thing, about acting within the norms served no role in my actions. And I loved every moment of it. This was over 30 years ago and the memory still makes me smile.
Sometimes when we take risks, we make mistakes. Elon Musk is a risk-taker extraordinaire. My risk-taking genes are much more modest. But Musk reminds me that my ability to thrive, to exceed my own expectations are limited only by my imagination.
Can you think of a time when you did the unexpected or broke the rules?
Published in Group Writing
I should add that Musk always believed that if deleting something made the product or process work, he would re-instate it or try something else.
I love how Musk always talks about the good and useful data they get when something goes wrong with a SpaceX rocket. He loves learning from mistakes, and that’s a good lesson for my students. They are paralyzed with fear of not getting the right answer the first time.
Most of us are conditioned in that way, fractad. It can be a challenge to break through that mindset!
That is what I do. Sometimes it has been my job. Eventually it became a reflex, like reaching for the radio’s tuning knob when a Nickelback song starts playing. It has saved time, money, schedules, projects, and subpoenas. It is known as the Great Nonsense Sieve:
Take all your so-called “requirements.” Put them in the Great Nonsense Sieve. Shake it a little. The bits that filter through are requirements you can actually test. The rest can be pitched as Nonsense. If there are particularly shiny bits of Nonsense that you really like, put them in the Pestle and Mortar of Cogitation and grind for a while. Dump the Mortar into the Sieve and repeat. You’ll end up with more testable requirements.
I am praying that Trump wins (and the results are not stolen) and Elon is given the authority to “delete, delete, delete”.
Yeah, when I cut off my long hair and joined the Navy. It was the second “best decision” I ever made in my life. The first was deciding to go to college . . .
What a creative and insightful process, Percival! I’ll bet people tremble when you enforce your expectations!
Wow! Those are big ones–especially the hair cutting! ;-)
I’m, generally speaking, pretty rules-averse (odd for someone in my religious circumstances, but then again…see exhibit A: husband). That attitude has served me well for many years as a scientific researcher. We question everything! It is not serving as well in my current clinical work setting, but I get by mostly by doing stuff under the radar. I work with someone who constantly quotes “best practices” as defined in the manuals. I say, “yes, dear” and go back to doing what works.
Good for you! It takes courage to work that way, and everyone is better off when you do.
That should be added to the list of “best practices.”
In George Gilder’s book, Wealth and Poverty, recommended to us by @drbastiat, @schrodingerscat, and others, Mr. Gilder agues powerfully that a nation’s wealth is inversely proportional to its regulation of business and industry. A permissive regulatory climate contributes to the wealth the citizenry.
System Requirements Reviews are fun. Well I have fun anyway.
Thanks, Susan, good article about the amazing Mr. Musk!
The following techie-type thoughts don’t take away from it, but may be helpful to you in future.
”Requirement” can mean “rule”, just as you assumed. And Musk is a master rule-breaker.
But in this case, perhaps Musk was using a different, specialized meaning. The word can be a bit of technical jargon used in various professions that involve designing and building custom products for clients, such as a custom house, a custom software application, a piece of military equipment built by a defense contractor, or a yacht (in which case the set of requirements is often called the “design brief”.)
* * *
Details
A “requirement” in this sense is basically a statement, in language understandable to workers further downstream in the project, of something that the client expects the system to be able to do for him (or not do).
Typically the Requirements Phase of a such a project is the first or second technical step in the project plan. A professional conducts it by interviewing the future users and other techniques to collect the input. The output is typically reported in the form of the “Requirements Specification”. This document, in a properly managed project, is the master input to the Design Phase of the project, as well as being an authoritative input to later stages including Implementation, Test, Training, signoff, and other stages even further downstream (like lawsuits!).
The software project methodology that became fashionable sometime in the early 20-aughts rejects this approach and this terminology, but it is a good starting point for understanding the technical definition of “requirement”.
It certainly contributes to the wealth of the country as a whole.
Mark, from what I can tell, I think Musk has a much more narrow focus on “requirement”; he’s usually talking about specifications, like why a piece of machinery has four screws instead of only two. And I don’t get the impression he’s much interested in what the end user wants; he assumes that they are mostly concerned with the overall package. Musk is mostly concerned with driving down unnecessary costs. I hope that makes sense.
I had the same thought. And if that’s what Musk means, he’s right: questioning the requirements is always a good idea, especially if they are based on what your customers have told you they want. Customers almost never really know what they want. If you ask them, they’ll happily give you a wish list, but there’s no guarantee that any of it will actually make them more productive. And some of it just isn’t practical at all.
The real trick is observing how customers use your product, notice where they’re having difficulty or wasting time, and figure out what they need even if they don’t know it. Steve Jobs had a knack for making products that nobody was asking for, because he was clever enough to figure out what people were going to want before they did.
Towards the later part of my 40+ years @ NASA I was regularly tasked with having to sit in on these initial system requirement reviews. I was known as a PITA.
Having spent the early part of my career trying to design & develop systems that met “the requirements” then finding out they could either not be tested, (so no verification), or they were irrelevant to the actual operation of a piece of hardware, I started to exact my revenge at those reviews. I would poke at the what a requirement was actually reducing in terms of risk or demonstrate functionality.
Sometimes I find out that stuff was just “mother hooded” boiler plated into the system requirements by the responsible engineer in a cut and paste fashion “because that is how we have always done it”. Yet the stuff they proposed to do no longer matches the state of tech we are flying (yes a bunch of stuff has changed in spaceflight over the last 40 years).
What I would not really relent on was testing. Especially in the environmental extreme the hardware would see at some point on orbit.
The one bit of hard nose attitude I had for those reviews has saved more than one project that thought it could economize on eliminating their full up environmental system testing. Project managers all try this rouse because it typically is the most expensive (and possible risky) testing an item heading into space will have to entertain.
Despite the evolution in electronics over my 40 years is that the digital guys will swear their stuff is impervious to temperature, yet we still manage to find some non fathomable failure that would have bitten our backsides in space.
Your welcome.
A very cool description! I’m so tickled to see so many people breaking out of the supposed “tried and true” requirements and do what is needed and what can be tested!
This is a good use of the Chesterton’s Fence question. I think a lot of times conservatives like to quote the question of “Before you remove a fence, figure out why it was installed in the first place.” as a way to defend tradition and fight against progressives’ all too eager desire to root up everything by keeping the fence up. As Elon points out, sometimes the answer is that the fence is just a hinderance and should be torn out. It’s still good to ask the question first.
A similar story to the pot roast one that I remember hearing is about a church congregation that always stood up and turned to face the back of the church to recite the Apostle’s Creed during the service. A new pastor arrived and wondered what this was about. No one initially knew. Finally, an old timer remember that the Creed had been hung on the back wall of the church but had been destroyed in the fire many years ago and not replaced.
Another perfect example, Bishop!
I see Bishop Wash just beat me to an addendum.
The Chesterton clause.
I would never just say get rid of something that has been “de Jour” since the 60’s, I would get the responsible guy to justify his boiler plate verbiage, as it applies to his hardware’s needs, especially if it was an untestable “motherhood” clause, and added nothing to his, or typically some other guy who becomes responsible, and hasn’t a clue to the requirement’s origins, yet has the responsibility to demonstrate.
Every System Requirements Review requires a PITA.
These are my thoughts, too, about what Musk meant. Being able to work out what the customer should have said he wanted is always the trick. It is extremely complicated, and doing it badly is why most software projects fail.
At your service.
It became my specialty, and despite my irascible reputation I was never asked to not come to a review by a project’s management.
They evidently understood that failing was even worse than having you around. :-)
Twice in my working life I went out on a limb in a major way in order to convince the people writing the code that the serious software “bug” we were experiencing was not the fault of the users, was not the fault of the support staff at my employer’s (in one of these cases the target of my determined pursuit was my employer, which was interesting), and that the problem lay with the product, no matter how many times the person at the other end of the phone insisted that he’d “never heard of such a thing,” and that “no-one else was having this problem,” and no matter how far up the food chain I went, while still hearing the same sort of guff.
In the first instance (1980 or so), I was working for a word processing company (it wasn’t Wang, but more people have heard of Wang than NBI, so let’s say Wang-adjacent). My boss, the branch manager told me I was making a stir, and that HQ was getting ruffled about my continued and insistent assertions. “Oh, well,” said I “I’m right.” The dear man backed me up. HQs next move was to send out to Pittsburgh one of the young men who’d worked in the first group of four or five young men who invented the product in a garage, six or seven years prior. (I don’t know if it was his mother, but one of their mothers donated a pair of panty hose which they cut up and taped over the screen as their first glare filter.)
He was a lovely man, one I suspect they didn’t let out of the glass house to speak to actual people very often. We got on like a house on fire, and–being more open minded than most I’d been speaking to–he spotted the problem–the bug–right away. I emerged with an enhanced reputation, he got on the plane back to Boulder, and–in a matter of days, the problem was fixed.
The second time was in the mid 90s. My community hospital, where I was the IT manager for desktops and networks, was implementing a computerized patient record system. The company was based in Seattle, and the product was developed by the company’s President, a man who had a patient list of about two people, whom he saw every once in a blue moon, just so he could still refer to himself as a “practicing physician” in the company’s PR blurbs.
The product ran a thin client on Citrix servers, and there was a printing bug. Once again, I got the “no one else is having this problem” song and dance, coupled this time by a very aggressive “you must be doing this all wrong” from the company CEO. Again I stood my ground. This time, he flew in from Seattle, I’m sure with the express intention of making a fool of me. He was that sort of guy, and had been talking behind my back to the physician champion in our family practice offices about what a dunce I was. (Oops. The doctor was a good friend of mine.) Strike One.
During our initial conversations, we determined that–although his tech support staff had been the ones to recommend the Citrix configuration for us and had posed as experts on the matter–we were the only one of their customers with such a setup, and they didn’t even have a Citrix server at their home office to test on. Oops. Strike Two.
Watching his face fall, as he went through all the motions himself on the keyboard, with his senior tech support person standing at his side, and then sent the document to print, and–OOPS! again–was one of the most rewarding moments of my work life. I’ll never forget it, or what a colossal [expletive] this man was, in every sense of the word. Strike Three.
I often took on the role after the fact and from the outside. And I enjoyed every moment of it, when I wasn’t stewing about the possibility I’d be fired from one or the other company (a distinct possibility, at least in these two cases) if I’d been proven wrong.
Excellent examples, She! How great that you stuck to your guns. And, also, sometimes revenge is sweet. ;-)
Of course, you might also have been fired if they remained unable to print things, and you didn’t get it fixed.