The Fast Pencil Fallacy in Software Development
codinghelmet.com
codinghelmet.com
The main problem in industry is not suboptimal badly designed software. The main problem is amount of outright failed projects. Not delivered or with zero adoption and zero deployment.
Arrogance in ignoring real-world pencil experience of our customers, inability to extract that experience is often the reason why software project fails.
A very few of us do study computers as computers, and they often are held up as the pinnacle of the field. We would rather discover algorithms or write tools for other programmers. But most of us make tools for people, and we can't do that well if we don't know what they need.
One way this shows up is in the way novice programmers fixate on the fastest language or algorithm, because it's a way they can show off their expertise to other programmers rather than a customer. They should be taught from the beginning that their job is to be useful, and it would be easier if they could be taught to be interested in something other than the computer for its own sake.
So in my world of anecdata you're entirely correct on how amazing domain knowledge is. I could help the psychologist with her research and could anticipate a couple of fun requirements (like an ever changing questionnaire :P).
For the same reason as you describe: Most software is meant to solve a specific application. In my current office we have people who are experts in programming but also in orbital mechanics (the math and physics of it all). That makes them invaluable to the customers (who also have experts in orbital mechanics but not in software).
Indeed. The contradiction of recommending focusing on user needs and missing the reader need for a concise, well written article doesn’t inspire confidence.
I also apply this advice to myself, my girlfriend and my friends/family.
It's worth it in the long run.
Oh, this is meant as business advice! Ah, I guess living life is a business, in a sense ;-)
I think that it depends on who your customer is, if it's a domain expert then you should listen to what she asks for, because she likely won't change her processes to fit your product. If it's not a domain expert then there's much more flexibility when it comes to process, you're able to educate.
"Your audience is good at recognizing problems and bad at solving them".
As soon as you presume that you know your customers problems better than you, you're in trouble, but it's totally appropriate to ignore the solutions they suggest to you.
2. That being said, there is a thing we used to call The “maturity model.” The customer using a pencil is very low in maturity. But leapfrogging past a fast pencil is often difficult.
Sometimes, customers have to evolve their way up the maturity model, so first you give them a fax machines (a fast pencil for sending documents by messenger), then you hook the fax machine up to their word processors (fast pencils for documents), then you wire the fax machine to the word processor so it can send faxes directly, then you introduce email and PDF, then you introduce collaborative editing, &c. &c.
Sometimes a customer can leap several levels of maturity in a single bound, but often not. The ones most likely to make a big leap are usually those with the least investment in their existing pencils.
So small shops, startups, young users early in their career are often good candidates for “you don’t want a faster pencil, you want collaborative editing.”
3. Nevertheless, I like the fast pencil analogy.
I like the metaphor and agree with this sentiment: "the problem of understanding what customer needs, as opposed to accepting what the customer is asking for".
A few points:
1. The customer has a say in the requirements. They are often the domain expert. Even if they have no expertise, they need to be regularly consulted otherwise you still run the risk of delivering software that no value to them.
2. Understanding the business and eliciting requirements is often beyond the ability and scope of the software developer. These are the skills of a business analyst. Of course, developers can and do have these skills, but it shouldn't be assumed that they do.
3. Proper business analysis may lead to a solution that doesn't involve custom software. The article doesn't seem to allow room for this.
4. Implementation is often important to the customer. Many won't be comfortable to leave everything "below the surface" to the software developer.
What is more important is to understand what the customer/user actually needs and solve that problem. Often times customers do not understand how software could make their life better.
In other words the customer might be asking for a faster pencil (the current tool) but what they really need is an email system.
^
^
The book also coined the term "affordance", which is still used today in UI discussions. One of the criticisms of flat design is that it removes affordances, in contrast to e.g. the 90s-era Windows 3D buttons which use a consistent visual language to indicate what elements the user can interact with.
This is a good article for people want to take freelance, or run software vendor firm, or to come up "startup idea".
If a business presently has a slow process that they want you to accelerate, they probably also batch it. That is, they gather a lot of that same kind of work together and do it all at once (whether each task depends on any of the others or not).
By accelerating (giving them a fast pencil), you make it feasible to break this batch cycle up, distributing the work more evenly either across people (it's clearer what small units of work need to be done so other people can grab and do the work as needed) or time (even if it's still one person, if the work is now entering three items in a field and approving or disapproving then it's easier to do "on demand" versus waiting until the end of the month).
This doesn't mean they will switch to small batches, but it means they can. If they choose to do this, the business will almost always see improvements in overall performance (assuming that those processes were ones that blocked other critical activities). Consider the improvement if this is purchase orders: The company isn't in the business of purchasing things but of doing X. The purchases, though, permit X to happen. If all purchases orders are batched at the end of the week or month, then everything else is stuck on that same cycle. If the purchases can now be evaluated and approved/disapproved daily (say the approver checks at 12pm and 4pm) suddenly everything else runs much better. (This is the basis of Theory of Constraints, with the assumption that the purchase is the bottleneck in this scenario for many/most projects.)
This is the transformation that businesses need to get to, but they can't break these cycles until they get something faster. And once they have something faster, real automation and improvement because feasible. It was technically feasible before, but the customer didn't understand what they were doing or they felt overwhelmed by it ("It takes us 4 managers and 5 work days at the end of each month to do X right now"). This is the basis of process improvement. You start by accelerating (in a sane way) the things that can be accelerated and removing the unnecessary things, then you start real transformation because it becomes visible where things can or should be improved. You gain greater focus and clarity with the freed time and mental resources.
I faced this repeatedly over the last few years at my previous job. Everyone felt overwhelmed. The office was in a chronic state of panic. They batched all their work, and it led to lots of issues because it created artificial synchronization points and constraints. The only way to make improvements was not to reinvent everything, that would never sell (I tried). It had to be incremental with fast pencils. Automate this test suite, automate that build process, automate the deployment process to the extent possible (embedded, there are physical blockers here), convert a manual business process to a proper workflow, etc. Each one freed up personnel and time and let people start coming back from that panic state. After that, then you can focus on how to really change and improve the business because now you're making as much money for half the time, but if you're smart you keep all the people. You can move them around, or take on more work. Or let them run experiments to try and improve other areas or other projects, taking their lessons with them.