
The Fast Pencil Fallacy in Software Development - ivanche
http://www.codinghelmet.com/articles/the-fast-pencil-fallacy-in-software-development
======
hamilyon2
Very long article that could be summarized in one phrase: do what customer
needs, not what he asks for. Not listening to what customer wants and treating
him like user instead is sure way to produce unneeded software.

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.

~~~
jfengel
If it were up to me, nobody would major just in computer science for a
programming degree. We should all have knowledge of some domain, any domain,
so that we at least recognize what domain knowledge looks like.

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.

~~~
mettamage
I studied psychology and outcompeted 10+ years experienced programmers when I
made a greenfield application for a psychologist when I was still studying CS
at university.

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).

------
braythwayt
1\. I love the “fast pencil” analogy, especially as I have used it for maybe
forty years(!) in various consulting, sales, and software design roles.

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.

------
obscura
Not the best of articles, IMHO. It has too many broad statements and seems to
be trying to be a "one size fits all" bit of advice.

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.

------
nkingsy
This needs examples throughout. I agree with the sentiment but I might argue
that initially studying the pencil is the best way to trace back to the
problem it solves.

~~~
stx
This is what comes to my mind from my personal experience. Your customer uses
excel spreadsheets to coordinate work. They ask you to move what they are
doing in excel into custom software that can be shared with other users. If
your not careful as a developer you end up re-inventing excel.

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.

------
sukilot
Please, just read Don Norman's _The Design of Everyday Things_ instead of a
hundred dashed out blog posts.

~~~
kristianp
What's that book got to do with designing software? Genuine question.

~~~
pjc50
Software is an everyday thing.

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.

------
aabbcc1241
This article look at vendor software from the perspective of business. e.g.
The users don't really care about the software itself, they use it as a tool
to (semi)automate solving the business problem.

This is a good article for people want to take freelance, or run software
vendor firm, or to come up "startup idea".

------
Nijikokun
So basically, listen to the customer?

------
Jtsummers
I think it's important to understand what the fast pencil might do for a
business.

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.

