To Robyn's point in particular, I believe the processes of rehearsing, visualizing, and planning have extraordinarily high value. Visualization and rehearsal are vital, in my opinion, to doing anything well. Ask pilots, athletes, actors, public speakers, programmers, .... Check out "Blue Angels: A Year in the Life" from the Discovery Channel for a really good example.
But there's a time when the incremental value of planning drops beneath the value of actually doing something. I think the location of that "time" and the concept of obsessiveness are related. I'm learning that it's earlier than I had believed when I was younger.
The one sentence in my original blog post that captures the idea I want to emphasize is, "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."
Thinking of all this reminds me of a "tree house" I wanted to build when I was about 10 years old. I use quotation marks, because it wasn't meant to have anything to do with a tree at all. Here was the general idea of the design:
My dad was a pilot, so when I was 10, I was too. The front of this thing was going to have an instrument panel and some windows, and I was going to fly this thing everywhere I could think of.I drew detailed design drawings, and I dug a hole. (If you have children, by the way, make sure they dig a hole sometime before they grow up. Trust me.) My plan called for a 2x4 frame with plywood walls screwed to that frame. It's when I started gathering the 2x4 lumber that my plan fell apart. See, I had naively planned that 2x4 lumber is 2 inches thick by 4 inches wide. It's not. It's 1-1/2 inches thick by 3-1/2 inches wide. That meant I'd have to redraw my whole plan. Using fractions.
I don't remember exactly what happened next, but I do remember exactly what didn't happen. I didn't redraw my whole plan, and I didn't ever build the "tree house." Eventually, I did finally fill in that hole in the yard.
Here are some lessons to take away from that experience:
- Not understanding other people's specs well enough is one way to screw up your project.
- Actually getting started is a sure way to learn what you need to know about those other people's specs.
- You learn things in reality that you just don't learn when you're working on paper.
- Not building the "tree house" at all meant that I'd have to wait until I was older to learn that putting wood on (or into) the ground is an impermanent solution.
- The problems that you think during the design phase are your big problems may not be your actual big problems.
4 comments:
Cary, that shows how special you are. My son was allowed to dig holes when he was ten, but any plans he worked on would not have been more detailed than a sketch of the finished product and would have called for "wood", not 2X4 lumber. I would have wound up determining the suitable materials or modifying whatever he scrounged out of my supply....
Hey Cary, very interesting topic. I totally agree with your main point. I have been a rapid development convert for a long time. I think you are in somewhat of a unique position in that you have been able to work on stuff that was basically your idea, where as most of us have had to build stuff that is essentially someone else's idea (usually a consensus of several other people's ideas).
Early on in my career I began to believe that it was impossible for anything close to complete specifications to actually be created for anything more than a very simple tool or script. It just seems to me that people have a much easier time pointing out what is wrong, than describing what is right. And that's why rapid development methods tends to be more successful than the older top down design and then build approaches. The longer you wait between showing the people whose ideas you are implementing, the more room for error there is. The ideal situation, in my mind, is having a user on the development team, sitting in the same bull pen area.
One of my early jobs was to build a system to determine whether insurance companies had correctly reimbursed hospitals, according to their contracts. When I started with the software development company, they had spent a couple of years with 25 or 30 people (all very knowledgeable in the field) designing a system and writing specs. When I showed up they had a set of binders that filled a shelf about 30 feet long. And not a single line of code had been written. The owner of the company had decided that they needed to use a database (Oracle) and so they hired me. Well about a week after I showed up, the owner ran out of money. He let everyone go except of a couple of programmer types. He can to town and sketched out what he wanted on a napkin (classic eh?) and we started building the next day. He was basically out of money so the within 2 weeks we were showing him stuff and it turned into a very short cycle, iterative development effort. It worked pretty well, and the owner got something that he could sell (even if it wasn't full grown yet, it still could do some things that were useful, and it could be shown to potential clients). He managed to sell it several times within the first few months, each time providing more feedback/ideas back to the development team. This was back in the mid 80's and I'm not sure when the iterative design concept became popular, but I had certainly never heard of it at that point in my career. When I read about them later, they made a lot of sense to me though. I probably had read "The Mythical Man Month" by then, so maybe the idea of prototyping was already implanted in my brain.
I will say one thing though, for me, the more mature a product becomes, the less effective this approach becomes. The sheer weight of the code itself starts to bog down the effort. Regression testing to make sure you haven't messed something up takes longer and longer. Also, the data model itself is crucial. That's where I would tend to spend the most time up front, because that's the most costly to change later.
Great post. You should post more often if you can work it into the schedule. (sorry the comment is so long)
Kerry
Kerry,
I'm thrilled that your comment is so long. Thank you.
Cary
Yeah, I guess I got a little carried away. It didn't seem that long until I posted it!
Kerry
Post a Comment