The conception, birth, and first steps of an application named Charlie

Subscribe: Atom or RSS

The Power of Two

by Alister Jones (SomeNewKid)

So far I am enjoying reading Getting Real. The authors take a very pragmatic approach to most of the problems of software development, which is a refreshing change from the stringent approach taken by most authors. What is interesting is that Getting Real presents many of the same arguments as Agile evangelists, but without the zealous fervour of those evangelists. With the zealots, it is very hard to see passed bullshit and through to the ideas. With Getting Real, there is no bullshit, so the ideas are right there to be learned and applied. It is a great book and I recommend it highly.

What I cannot recommend, however, is the advice on the page entitled, “Done!” The idea presented on this page is that decisions are temporary, a poor decision is not the end of the world, so just make a decision and move on. I think this is poor advice.

Earlier in the same book, a quote is presented from The Pragmatic Programmer by Dave Thomas. The quote is as follows:

“As the designer or developer of a new application, you’re faced with hundreds of micro-decisions each and every day: blue or green? One table or two? Static or dynamic? Abort or recover? How do we make these decisions? If it’s something we recognize as being important, we might ask. The rest, we guess. And all that guessing builds up a kind of debt in our applications—an interconnected web of assumptions.”

I feel that if a developer accepts that all decisions are temporary and relatively unimportant, then the developer is just going to start making guesses so that he or she can get to “Done!” as quickly as possible. As Dave explains, this builds up a kind of debt in the application. And like all debts, it will become due for payment at some later date.

During the development of Charlie, I have noticed that I have evolved my own approach to making a decision. First, I will read just enough about the subject so that I understand the issues involved. Then, I will read how Microsoft recommends that a particular problem be solved. Next, I will put pencil to paper and see if I cannot come up with a simpler solution. Only after comparing Microsoft’s recommendation against my own ideas will I make my decision. That is, I end up comparing two recommendations: Microsoft’s and my own.

Throughout this weblog, you will have noticed that I often say, “There are two main approaches,” or “There are two possible solutions.” Often they are salt-and-pepper options; one will be direct and one will be indirect, one will be simple and one will be complex. Again, I end up comparing two approaches.

I feel that two is a good number. If you don’t evaluate at least two alternatives, then you’re really just relying on gut instinct, which is little more than an outright guess. Conversely, if you try to evaluate more than two alternatives, then you probably haven’t yet distilled the problem down to its core. At the core, most problems have two forces pulling in different directions: direct against flexible, simple against complex, developer against user, and so on. If an issue does involve more than two forces, I reckon the issue qualifies for being broken down further, again and again, until you end up with a set of easily-stated problems, each with just two main solutions. Then, you need to decide between the two. That will be a true decision, not a guess masquerading as a decision.

So this represents a different approach to that recommended in Getting Real. Rather than getting to “Done!” as quickly as possible, I will aim to get to “two” as quickly as possible, and then make a decision.

by Alister Jones | Next up: The Interface. The Chicken or the Egg?

0 comments

----