Tell me What to Do, Not How to Do It! by Bruce Nielson
Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity. – George Patten
This sounds like good advice doesn’t it? It is, actually, but we need to understand it correctly.
The first thing we need to notice is that there is no objective difference between ‘what’ and ‘how.’ The difference is purely relative.
If I’m a marketing guy, I’m going to give you a ‘software spec’ that might be a series of bullet points that says:
- Make the Whiz-Bang 50% faster to improve the user experience
- Add the Gog Widget everyone keeps asking about
- Enhance the Dribblium feature to automatically look up user information
If I’m the marketing guy “what” I’m doing is increasing sales. “How” I’m doing it is by the feature improvements listed above.
But to the team manager, this looks a lot more like a list of “what” needs to be done with no details on “how” to do it.
So the team manager takes this list of bullet points and creates what we (mistakenly) call “detailed requirements.” He now carefully lays out the details of “what” needs to be done but decides to leave it up to his tech lead on “how” to accomplish it.
The tech lead then creates what is (mistakenly) called a “detailed design” where he makes a bunch of UML and designs out exactly “what” he wants his programmers to do but still leaves it up to them on the specifics of “how” to implement that design.
Interestingly, the programmer then writes the code which, from the compiler's point of view (do compilers have points of view?) is really a specification of “what” the software needs to do, but leaves it up to the compiler of “how” to do it.
So based on this example, we must accept that “what” and “how” are purely relative to a point of view. They do not objectively exist.
Perhaps this is why we don’t usually make a separation between “what” and “how.” They tend to mingle freely in our minds. Have you ever called your spouse and said “Hey, what time were you planning to be home?” when what you really wanted to know was “How much longer can I stay out with the guys/girls?” I do this all the time.
This is actually useful to know. Because it means that you never have to take an instruction as “how” you have to do your job because what people actually care about is “what” they wanted to accomplish.
I remember a customer that insisted that a certain field, I think a zip code, was to have exactly 6 characters in it. This was a hard fast requirement.
It turned out that they were used to a DOS-based program where the program moved to the next screen upon finishing typing in the last field on the previous screen. The zip code was the last field, so they wanted to be able to enter it and not move to the next screen before having a change to review it. (For those of you under 30, DOS is a quaint little program that lets you type stuff and then it deletes all your files)
Of course in a windows based program (for those of you under 20, Windows is that thing you see just before you click on the browser) this was a non-issue. The correct ‘requirement’ was actually “allow me to review the screen before I move to the next” which is built into windows anyhow.
But that’s my point. You should never just assume that because your customer told you “how” to do something that they weren’t actually trying to tell you “what” to do and just didn’t know how to ask it right.
So don’t just blindly follow requirements. Instead, make a real effort to understand ‘what’ the customer really wants to accomplish and come up with your own suggestions of ‘how’ to accomplish it. Think of requirements as the starting point of the discussion, not the ending point of ‘what’ you’ll finally deliver.