Friday, December 19, 2008

Cuts, Thinks About Cutting

This xkcd comic I saw today reminded me of a conversation a former colleague at Oracle and I had some years ago. During a break in one of the dozens of unmemorable meetings we attended together, he and I were talking about our wood shops. He had built several things lately, which he had told me about. I was in the planning phase of some next project I was going to do. He observed that this seemed to be the conversation we were always having. He argued that it would be better for me to build something, have the fun of building it, actually use the thing I had built, and then learn from my mistakes than to spend so much of my time hatching on what I was going to do next.

I of course argued that I didn't want to waste my very precious whatever-it-was that I would mess up if I didn't do it exactly right on the first try. We went back and forth over the idea, until we had to go back to our unmemorable meeting. I remember him shaking his head as we walked back in.

Sometime after we sat down, he passed a piece of paper over to me that looked like this:It said "cuts" with an arrow pointing to him, and "thinks about cutting" with an arrow pointing to me.

Thus was I irretrievably labeled.

He was right. In recent years, I've grown significantly in the direction of acquiring actual experience, not just imagined experience. I'm still inherently a "math guy" who really enjoys modeling and planning and imagining. But most of the things I've created that are really useful, I've created by building something very basic that just works. Most of the time when I've done that, I've gotten really good use out of that very basic thing. Most of the time, such a thing has enabled me to do stuff that I couldn't have done without it.

In the cases where the very basic thing hasn't been good enough, I've either enhanced it, or I've scrapped it in favor of a new version 2. In either case, the end result was better (and it happened earlier) than if I had tried to imagine every possible feature I was going to need before I built anything. Usually the enhancements have been in directions that I never imagined prior to actually putting my hands on the thing after I built it. I've written about some of those experiences in a paper called "Measure once, cut twice (no, really)".

Incremental design is an interesting subject, especially in the context of our Oracle ecosystem, where there is a grave shortage of competent design. But I do believe that a sensible application of the "measure-once, cut-twice" principle improves software quality, even in projects where you need a well-designed relational database model. I'm not advocating that design shouldn't happen; I'm advocating that you not pretend your design is build-worthy before you can possibly know.

Some good places where you can read more about this philosophy include...

Often, when a company wants to build an application, they start to think about every feature they ever might need. This causes long implementation periods (over time and over budget) and at the end the application is still not having the features they actually need.

With incremental design the end-users see much quicker a result and the company learns about what they actually need from the application.

But, they must be prepared at the possibility that at a next iteration, they will have to throw away all existing code.

The database releases of Oracle tells us the benefits of multiple cuts. Bob Miner who was the architect of Oracle until Release 6 and even into 7 was a perfectionist but did not allow that to stop releasing versions of Oracle that were good enough. Oracle Release 10g with its RAC implementation over an interconnect is the last great feature IMHO. It took Oracle 23 years to get there.

This echoes what Fred Brooks knew already in 1975 when he wrote his famous "Mythical Man Month": "Hence, plan to throw one away; you will, anyhow." He makes the interesting point that basically every time you create a software system you do it the first time; if it wasn't the first time you could buy it already. So it's always new and you need the learning experience to better understand the domain and create a better (or usable at all) system.

That's a great point. I learned it again over the past week in my woodshop. I'm trying to build something for a friend. It has turned out to be nothing more than a pile of garbage. I planned the heck out of it, too. Precise technical drawings, lots of mental rehearsing about construction, ...none of that matters. At least I had the good sense to build the first one out of really cheap material.

I have a thought and maybe I am completely off with this but perhaps the Agile Project Methodolgy can play into this thought model. I have seen this methodology in action and when I read your article I immediately thought of it....what do you think?

Exactly, Will. Check out the "Measure Once, Cut Twice" paper, which goes into more detail about incremental design and weekly builds, two of the cornerstone concepts of the Agile method called eXtreme Programming (XP).