Don't believe anything you read on the net. Except this. Well, including this, I suppose.
I'm writing this on March 11, 2013, what would have been Douglas Adams' sixty-first birthday. If you do not know who Douglas Adams is, or you recognize the name but never read anything that he has written, you have robbed yourself of one of the greatest reading pleasures known to man or little furry creatures from Alpha Centauri. Adams died way before his time in 2001, but while he was alive he shared numerous, unintentional pearls of wisdom about software development and knowledge work that are as relevant and chuckle inducing today as they were when he wrote them. For example: I really didn't foresee the Internet. But then, neither did the computer industry. Not that that tells us very much of course—the computer industry didn't even foresee that the century was going to end.
In honor of what would have been Adams’ sixty-first birthday, here are some of those nuggets and my take on what they mean today.
Software Development Is about Solving Problems
A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. (Mostly Harmless)
What Adams refers to here is really a quest to help solve problems that people and organizations face and a subtle warning to not get too wrapped up in trying to provide the perfect solution. A good solution sooner is much better than a nearly, but not quite, perfect solution later. Don't let a quest for perfection, which you may never reach, prevent you from sufficiently solving your shareholder's problems now.
Software Development Is about Solving the Right Problems
I have a well-deserved reputation for being something of a gadget freak, and am rarely happier than when spending an entire day programming my computer to perform automatically a task that would otherwise take me a good ten seconds to do by hand. (Last Chance to See)
Many of us got into software development because we enjoy solving challenging problems and because we like tinkering. But to be truly effective, you must know which problems are the right ones to solve. You can't answer this alone. It's best to work with your stakeholders to come to a common agreement as to what the problem is and why it is worth solving.
Many stakeholders don't take this perspective. They often run into a problem and cook up some solution based on what they have seen work in some other context. You may get some resistance when you try to get the stakeholder to step back and explain the real problem they are trying to solve and let you provide options, but it is really in their best interest. More often than not, once you understand the true problem, you'll be able to provide a simpler solution, quicker, than had you just done what the stakeholder initially asked you to do.
The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair.