I was just talking to Keith, a good friend of mine from Sacramento (and the best realtor in town, I might add) and he told me a story about a recent road trip to Oregon.
He and his wife were meeting some friends at a beach house in the middle of nowhere and although they had the address, through a twist of fate they didn’t have directions or a map. Now, in my case I would have hopped onto Google Maps using my new Treo SmartPhone (a used Treo 300 I recently purchased used for $80 on eBay – crazy deal!), but then again there probably wasn’t any cell coverage. Rats!
After driving around for a while they elected to stop at a gas station and ask for directions. The directions included things like “turn off the paved road” and “you’ll have to stop and move some branches to get through this next part,” but with the help of that very nice man they eventually made it to their destination safe and sound.
This tale reminded me of several software projects I’ve worked on.
Software developers, by nature and necessity, tend to be focused individuals. To be productive they must slip into a state of intense concentration that most people call “the zone,” but psychologists refer to as “flow.”
By far the most productive time for a programmer is when she’s in the zone, and it can yield three of four times the software (or more, some argue) than when working at her usual pace. Joel Spolsky has covered this many times from many different angles, so I’ll try not to go into too much detail for risk of boring the avid Joel fans (I’m included in that category – see “My Daily Reads” at right).
When in the zone, an algorithm, which is a specific approach to solving a complex problem, become deconstructed into its finest details and sits like a swan, carefully perched in the programmer’s head. As he writes code, the next detail in his mental queue magically surges from his fingertips, instantly translated into the programming language as if it were his native tongue.
These are not conscious steps a developer has to think about or is even aware of, in much the same way an olympic 100 meter runner does not have to think about placing one foot in front of the other; it’s nothing but effortless motion.
The beauty of the zone is the productivity it generates. I’ve personally had 8 hour blocks where I’ve written enormous amounts of software; tasks that would typically take several days to complete.
The curse of the zone is that it’s like a hitting streak; it’s difficult to attain and even harder to hold onto. One distraction can easily bring you out of the zone for 10 minutes or more and may bring you out for the rest of the day. Heck, half the time I’m distracted I wind up checking email, getting some water, and talking to the person in the cube next to me, which pretty much ensures it’s going to take a long time to get back into it.
How Programmers Attack Problems
Since the introduction of the first procedural programming language, ALGOL, in the late 1950s, programmers have been reared to think in small blocks of functionality, also known as functions or subroutines. The process of thinking in small chunks is an easy way to describe and ultimately build a large system that is too complex to understand in its entirety.
As an example, if you hand a programmer a spec that says:
- Build an e-commerce website
The first thing they will do is break it into smaller pieces, like so:
- Build a few product pages
- Build a shopping cart page
- Build a checkout page that collect address and credit card information
- And so on…
So Joe Developer is handed a spec that provides a nice, high-level view of the project and tells him where he needs to end up. He breaks it down into smaller steps, then perhaps into even smaller ones. He takes those tiny steps and begins to translate each one into instructions the machine can understand (aka “writing code”).
Soon after the first or second step he comes upon a task that he can’t easily translate into code. Perhaps it’s a piece of data he needs to display that doesn’t exist in the database, or maybe there isn’t enough detail in the spec on how to implement a particular feature.
Not only does he have to stop what he’s doing, but he has to make a phone call, walk to someone’s office, or schedule a meeting in order to get the answers he needs to continue. This is a tremendous waste of time in the sense of “he wasn’t at his desk for nine minutes while he asked this question,” and it also takes his “flow” and sends it via Pony Express to the other side of the universe.
But there is a solution.
Have Your Best People Write Your Specs
Average developers or average business analysts write average specs, and they will cost you tenfold in time, money, and frustration because your best programmers spend priceless hours sitting in conference rooms or, worse yet, sitting at their desk thinking about who they need to talk to in order to get the answers they need to do their job. You may have heard the old software adage (paraphrased and modified):
“A flaw caught in a spec takes 1 minute to fix. A flaw caught during development takes 10 minutes to fix. A flaw caught during testing takes 100 minutes to fix. A flaw caught after release takes…well…let’s just say more than 100 minutes.”
The details that have the greatest impact during development are the unsolved business and architectural issues. These issues must be brought to light before development begins, and the best way to do this is to have your best people writing your specs.
So how does this relate to my friend’s trip to Oregon?
He left Sacramento with the goal of arriving at a beach house. The spec he had gave him a high-level view of where he needed to end up:
- 123 Old Country Road, Brookings, Oregon
But what he really needed was:
- Take I-5 north to the Main Street exit in Brookings
- Turn left at the bottom of the ramp
- Drive 3 miles until you see a burned down gas station, then make a left off the paved road
- And so on…
If you feel like developer productivity is in the tank, take a look at your specs. Make sure they’re keeping you on the paved road.
Photos by Sherry