Members compete for most frustrating Web dev experience: Our second-place winner

Finishing a respectable second place in our most frustrating Web development experience contest, Mike DeWolf describes his attempt to overhaul an existing portal. Much of Mike's frustration was caused by his client; see how he overcame it.

In a recent article, we asked you to send us your most frustrating Web development experience. Those experiences chosen as most frustrating by our panel of judges received some free stuff from Builder.

Additional information
Check out the original article for contest rules:
"Turn your most frustrating Web development experience into free software"
Other winners:
Third Place— T-shirt (winner wishes to remain anonymous)
Fourth Place— T-shirt
Fifth Place— T-shirt

In another illuminating story of frustrating Web development, our second-place winner, Mike DeWolf, describes his attempt to overhaul an existing portal. Overcoming the expected technical barriers and the extraordinary barriers inflicted by the client, Mike was able to successfully reach the ultimate goal. For sharing his experience with us, Mike received Macromedia's Dreamweaver MX (retail value $399). Here is his story:

Don't give me what I ask for—give me what I need
I have had good and bad experiences with clients. Some have ripped me off. Some got disgruntled when their site didn't take off like Yahoo a day after they launched. A number of them had two sets of requests: what they asked for and what they wanted. They would set their budget cap at what they asked for, but set their expectations at the lofty height of what they wanted. The most profound example was a Web entrepreneur who ran a local Web portal.

I had looked at his site every now and again. I thought, "Great idea, good marketing, shame it sucks." The site was well publicized, and he had a business listing fee of $25/year—about a third of the cost of his nearest local competition. I was introduced to the site owner through a mutual contact. He shared his misgivings about the site and how it functioned. He also had hopes for what it could do. I was eager to take on the assignment of making it functional.

I asked for a copy of the database and the preexisting design. Because he wanted to keep the database and some of the preexisting design, I didn't think this was a far-out request. Well, they didn't come. As he put it, "If I give you those, you might repeat the mistakes I am trying to solve."

I took that dead canary in the coal mine in stride. From his perspective, this caution was understandable. He complained that the old site kept crashing and his former developer couldn't keep the site running for a month at a time. It turned out that his ODBC connection to the Web-based database would crash the server whenever he made an update or inserted a new record. Because he was so fidgety, he was making changes to the data and the data schemas daily. That meant his site was crashing daily and fueling his need to distance himself from that situation.

Like a donkey running from the cart it was pulling, he had problems. He pulled the project off course and away from the spec, but I made the decision to keep working because of the promise of this site and my zeal to see it through.

I had a lot of tasks before me: database development, automation, developing admin tools, and building a useful search engine. You know how search engines grab anything relevant? That's what I assumed he wanted. I worked to build a search engine that would search with some intuition. Stick in a postal code and it will look for a postal code, but not search the phone numbers. Stick in a phone number and the opposite will happen. I was pretty pleased with the scripts. My client was not.

For example, when you typed in "Knot Garden," you got the "Knot Garden" listing as well as a company that did one thing—tour Knot Garden. My client thought that was too hazy. He wanted the Knot Garden listing, but not the near hit tour guide. He wanted it to be more than choosy—he wanted it to omit really close matches on purpose. He said he had done this on his database, but he wouldn't give me a look at that so I could duplicate it for him. I put on my Kreskin hat again and duplicated his work.

Personal meetings were a nightmare. When I asked a question, my client turned to his computer and did all of these esoteric database queries. He sometimes took so much time that I forgot the question I had posed. When I asked about an automatic expiration date for old listings, it took 90 minutes to get an answer.

He had 2,500 listings in his portal. In a region where there were probably 6,000 potential listings possible, this was laudable. His competition had something like 200 or 300 listings. I was worried that any severe migration foul-up would cost him 2,500 clients and tens of thousands of dollars. Because of this potential, I pressed him for a migration plan and a date for the swap to the new system so that we could send out notices to his many clients. Then, one little detail emerged.

Only six of the 2,500 were paying customers. The rest were listed because my client was so eager to have a complete listing that he was willing to list people for free and without their knowledge. He had painted himself into a corner. Why would someone pay $25 when they were already listed? Why would someone pay when 99 percent of the other members didn't pay? If he dropped the unpaid listings, his site would then look like the sad competition with only dozens of listings.

The site also had 1,800 categories to track these 2,500 listings. Talk about too many chiefs and not enough Indians. Like Yahoo, the categories broke into layers of subcategories. He just went nuts when it came to categories. A good example: "Restaurants: dine-in and take-out: take-out: burgers." I asked about "dine-in and take-out" as a subcategory and wondered what other kind of restaurants there were. (Maybe there's some sort of "doorway" dining experience where they serve at a table in the doorway and you eat out of paper bags.) Worse still, there were some 600 empty categories—totally empty—and another 700 or so that had only one entry. It was just another dead canary.

In the end, he got the site I promised, plus an e-commerce component and a lot of extra work. It did take longer than promised, but take into account the 90-minute snipe hunts for answers, the scripts he withheld to make sure I had to rebuild the same functionality from scratch, the database I had to build via seance, and the warranty period that lasted 10 months longer than was contracted, and he got what he wanted.

What can we learn?
Mike's story is a prime example of the kind of frustration that can be caused by a quirky client with conflicting agendas. Do you have a plan or a system in place to manage client-induced feature creep or midterm specification changes? Share your techniques with us to help others avoid the frustrations Mike experienced.