Entries from June 2005 ↓

New Article: Bad Specs Hazardous to Productivity

Here’s an excerpt from my new article, Warning: Bad Specs Hazardous to Productivity:

“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 a conflict emerges that would break existing code if implemented. 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 not only a tremendous waste of time in the sense of “he wasn’t at his desk for nine minutes while he asked this question,” but it takes his “flow” and sends it via Pony Express to the other side of the universe.”

Read the complete article here

Warning: Bad Specs Hazardous to Productivity

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.

The Zone
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).

Costa Rican Beach

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:

  1. Build an e-commerce website

The first thing they will do is break it into smaller pieces, like so:

  1. Build a few product pages
  2. Build a shopping cart page
  3. Build a checkout page that collect address and credit card information
  4. And so on…

Costa Rican Waterfall

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:

  1. 123 Old Country Road, Brookings, Oregon

But what he really needed was:

  1. Take I-5 north to the Main Street exit in Brookings
  2. Turn left at the bottom of the ramp
  3. Drive 3 miles until you see a burned down gas station, then make a left off the paved road
  4. 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

E-Dreams captures the exuberance of the late 90s

I watched E-Dreams last night. It’s the story of Kozmo.com, the company started by two 28-year old investment bankers in the late 90s. Their idea was to sell books, movies and snacks online with delivery via bike messenger in under an hour.

They raised $250 million in three rounds of funding, expanded to six cities at their peak, and ceased operations in early 2001 after an aborted IPO.

The part that struck me most is how “Lord of the Flies” it was. The filmmakers did a fine job of adding fuel to this perception as they focused on the young CEO & his partner instead of the “adult” executives they show early on in the film. Late night beer bash aside, I couldn’t help but feel the chaos of the CEO’s inexperienced, albeit passionate, leadership. At one point in the film he comments that he has around 2,500 un-read emails. 2,500?! How could a company possibly stay in business with that many questions going unanswered?

Money.

There was so much investor money floating around it didn’t matter if they lit their cigars with hundred dollar bills; they just needed to show up for work. Once the investment dollars stopped they were out of business in a few months. The co-founders are now in school getting their MBAs.

While the whole experiment wound up a failure, I can’t help but wonder if in 2005, growing organically with a small amount of funding, a Kozmo.com could become profitable.

Amazon offers an $8,000 "Instant Library"

A great article on Amazon’s new offering: an $8,000 collection of the classics consisting of 1,082 books (700 lbs. worth of reading). At one book per week it would take 20 years to read.

The shipping charge? $3.99.

You don’t have to take my word for it…

…take Microsoft’s. They announced RSS support in Internet Explorer 7 and Longhorn (the new OS expected to release in 2006). Joe Wilcox discusses the Why and the What of this landmark decision. RSS is poised to become the next big medium for information exchange.

This is why you need to start using an RSS Reader.

MSN Search Spoof

If you haven’t seen the MSN Search Spoof (and sent it to every one of your friends), you must check it out.

Why you need an RSS reader

If you’re a “regular” in the blogosphere and you’re not using an RSS reader, you really need to start. An RSS reader is like email; if you’ve never used email it seems like nothing more than a complicated way to send a letter. But once you give it a try you’ll wonder how you got by without it.

The short story of RSS is that it allows you to subscribe to different “feeds,” which are typically blogs or news sites, and every so often your RSS reader checks the feeds for new items.

Before RSS I had a huge list of IE Favorites that I would click through every morning. Now I sit back and let SharpReader gently notify me every six hours if something new has been posted to any of the blogs I monitor. Even if you’re not an everyday reader, it’s still an excellent way to monitor the happenings in your favorite blogs.

If you’re interested, here are a few RSS readers to check out:

FeedReader and SharpReader are two of the most popular and are easy to install and use. I chose SharpReader because it’s written in C#, is extremely configurable, and has excellent OPML support (OPML is a standard way to import and export your subscription list).

Pluck is also popular, and offers both an IE plug-in and a web-based version.

Mozilla’s Extension Room has several Firefox RSS plug-ins in their “News” section.

If you still aren’t convinced, sign up to receive an email when I post something new (located in the sidebar at right).

Freakonomics

I listened to the Freakonomics audio book recently. Talk about a page turner (or in this case a CD changer). The topics are scattered but the book is surpisingly engaging. I found myself arriving at work in the morning and sitting in my car until a chapter ended.

The tag line is “A Rogue Economist Explores the Hidden Side of Everything,” and the book details several studies performed by economist Steven D. Levitt involving everything from abortion to the KKK. Levitt analyzed mountains of data and arrived at some shocking, but well-reasoned conclusions.

Looking at four years of detailed financial records for a crack gang reveals that the local drug dealer makes less than minimum wage…around $3.30 per hour. Levitt describes how teachers helped students cheat on standardized tests and how it was discovered through the analyses of answer patterns. And he discusses the statistical circumstances that lead sumo wrestlers to throw matches.

With many of his conclusions controversial (such as abortion rates affecting crime rates) it’s obvious Levitt has taken great pains to prepare his side of the argument. Over and over I found my skepticism washed away as he addressed one possible flaw after another, until finally there was nothing I could do but agree with him.

The People Business

There are too many software blogs.

Don’t get me wrong, there are a lot of brilliant developers in our industry. But we’ve gone from sharing technical knowledge using books, which take 9 months to hit the shelves, to using monthly magazines, to weekly online articles, to technical blogs that are updated daily. How much new, worthwhile information can we possibly generate on the same subjects? Even worse is that blogs don’t have that careful noise filter that books, magazines and most online articles have: an editor. Anyone with a finger and an eMachine can crank out content. Some of it’s good, some of it’s bad, and a whole lot of it seems to be about software.

But I love software. I love the feeling of starting with a blank screen and creating a brilliant application with nothing but two hands and my good pal Mr. Qwerty. And great software tends to be made in one of two ways: through pure genius or dumb luck. It’s like leaving a piece of bread in your cupboard for a month; you may get mold or you may get Penicillin. And you need to know something about them to tell the difference.

At my first job out of college my boss, the CEO of a large electrical contracting firm, was known to ask employees:

“What business are we in?”

Most would say “electrical contracting,” which seems like a reasonable answer given the fact the were, in fact, in the electrical contracting business. But to this he would reply:

“We’re in the people business. The biggest reason we’re successful is because of our people.”

Since those days I’ve been a firm believer that every one of us is in the people business (no matter how much you might wish it weren’t so). That’s why I’ve chosen to use this blog to address the human side of creating software.

In the end it may be mold or it may be Penicillin. Stick around and decide for yourself.

And so it begins…

Over the next few months I plan to write several articles about the human side of software development. Keep an eye out for discussions on the myths of software consultants, how to hire fast, how to talk to engineers, and explanations of software development in terms that even the people in finance can understand.