The Snowball vs The Zen Master

Image via Wikipedia

How It Begins

Your company develops accounting software.

The user asks the sales guy if there's a way for the system to show all people over 120 days in arrears & they'd send a dunning letter to those people.

The sales guy talks to the product manager: "Some of our users want a feature to create dunning letters on the fly."

The product manager talks to the system architect: "We need integrated word processing with a catalog of stock letters: collection accounts, new accounts, reminders, happy birthday cards...the works!"

The system architect tells the developers: "We're adding integrated document management to our system. We'll wrap everything around MS Word to save development time."

The developer tells the project manager: "The new features require new components. Also we need to extend the security to the new module, rework the backups, completely revise the graphics, and who's going to develop the content and write the documentation?"

The QA person collapses on the floor, moaning: "This will take a year to test!"

A year later they show the new system to the user.

"Nice," he says, "But have you worked on my dunning report yet?"

I read a blog entry about "Practicing Product Minimalism" and feel that people commenting on it really don't get the zen of "maximizing the amount of work not done."

Developing software is a lot like rolling a snowball down a hill. It starts out easy, picks weight along the way, becomes a juggernaut, and good luck to anyone who tries to stop or slow it down. Eventually, if you're lucky, it hits a brick wall and stops. If you're unlucky it takes out some of the team on the way down.

That's why it's necessary to question every new bit of work going into a project. Talk to users and be sure you understand what they want. Moreover, keep the feedback loop short: show them your solution as soon as possible. Make a paper prototype if necessary...draw it right there during the meeting.

New features tend to multiply tasks. For example, one new feature may be multiplied by security, storage, UI, graphics, documentation, configuration, backward compatibility, operating system compatibility, and hardware requirements. If the user has asked for a button with two states: [Stop] and [Go], don't assume they want a third state for [Slow], or that they want to be able to configure a set of buttons [Stop],[Go Slow], [Go Faster], [Go Fastest]. Or even that they want to be able to provide Urdu translations of the text of the buttons. Instead: stop and ask them before developing anything.

User priorities are also hugely important to maximizing work not done. Develop your software as if the next feature is the last feature, so it had better count. If the feature you're working on right now isn't the most important item on the list for the user: don't do it.

If you had practiced the zen of minimalism the user would have had the dunning report in a couple of weeks instead of a year later, and you could have used that year to develop more vital solutions. That's the payoff for practicing the zen of minimalism.