Coding is JUST like carpentry

Coding is JUST like carpentry, except with keyboards and mice instead of hammers and saws. Ok, ok, that analogy breaks down pretty quickly, but the thought did occur to me today. Let me explain. During the summer months my church spends the summer doing service projects like picking up trash and painting houses. With our recent tenant finish snugly under our belt we ventured out into the construction field to flex our power drills and sawzalls and help a smaller church in need.The victim, err church-in-need, was in northern Missouri and desired a wheel-chair accessible ramp built on the side of the church. Four of us climbed in a car this morning with a trunk laden with power tools and made the two-hour drive to Oregon Missouri. I had more fun today than I have had in a long time. It was also nothing short of a disaster. We didn't get the ramp finished either. The project was sight-unseen. Phone calls and text messages with our pastor had been the only communication about what needed done (bless his heart). It turns out the church didn't look at all like we thought, and best of all-- the alleged door the ramp was to lead to didn't even exist yet. They had concocted a trailer full of lumber and assorted boxes of decking screws from the hardware store, but there was not an actual bill of materials that had been drawn up. This, mostly due to the fact that there was no blueprint, no plans, and no leader. By the time we arrived and scarfed lunch it was 1:00 in the afternoon. The next hour and a half were spent making hasty sketches on paper and changing our minds. We finally cut our first board at 2:30 pm. We had to call the day short at 4:00 pm with very little completed. Needless to say, there will need to be a return trip (or two, or three) to polish off this job. Now, those of you still reading may very well be wondering what the heck this post has to do with ColdFusion OR Technology. I promise I'll tell you, but first let's itemize our failures. (I love this part)

• Precise project requirements weren't set in place prior
• Clear, rich, communication was not present and many assumption were made (and we know what happens when you assume
• Assembly phase started before planning phase what finalized
• Accurate estimates of resources were not made
• No clear leadership was defined for the team
• Scope and depth of the requirements steadily crept forward even after work had begun
• An absurdly short amount of time was allocated to complete the project

Now, if you had ONLY read the list above, what's the chance you would have thought I was describing your last programming project? Coding projects often suffer from the exact same shortcomings that other real-life ventures endure. There is no one person whom the shameful blanket of blame can be laid upon, but the far more important point is, "What suffers as result of a poorly planned task?" In our case, dear old brother Cecil and his wheel chair will just have to wait a little longer to roll into the sanctuary in high-style, but the stakes of your projects are probably much higher and involve more money. There is a reason the coding portion of the Development Life Cycle is only small part. If any project is worth doing, it is worth doing well and that involves planning. If you haven't gotten your issue of the latest Fusion Authority Quarterly Update, get it and read Peter Bell's excellent article called "Improving Your Estimates". If you want to grow your team into a stellar code shop you've got to start by acting like one. This public service announcement was brought to you by a 7/8ths spade bit and a compound miter saw.