Felix Writes: Client vs. Web developer: a quick guide

DigitalThoughts / Client vs. Web developer: a quick guide

2010-07-31

With the Web becoming more prominent in everyone's life, it is only natural that sooner or later many people will end up being involved in a Web development project, either as a client or, why not, a developer. Trouble is, most people -- on both sides! -- don't really know how to conduct such a project, and they end up running into the same problems again and again. This tends to lead to stress and losses on both sides, which is too bad, because after 11 years of working in this field I can pinpoint almost all failures to the same few causes. Let's see what they are and how you can prevent things from going awry.

Estimating

Advice for the client: don't ask for ridiculously precise estimates. So, you've just given the developer the elevator pitch for your project and asked for a time and cost estimate. No offense, but do you seriously expect to receive more than an educated guess at this time? If you have a hard deadline and/or budget limit, say so. But don't ask for a prediction of the future; you might as well use Tarot divination to find out how the project will unroll.

Advice for the dev: help the client understand why you can't give them. Look, it's easy to forget that your client is a layman, but he has no reason to know all the things you do; explain politely that software development is not like building houses or bridges, and even these activities are fraught with uncertainty. Do give an order-of-magnitude estimate, you can be that precise and it's better than nothing.

Specifications

Advice for the client: tell the developer what you want to achieve. This may come as a surprise to you, but Web developers cannot read your mind. Nor can they divine the functioning of a third-party Web service just by looking at it. Doesn't work that way. Better yet, don't try telling the developer how your application should operate; there's too much detail, you can't think of everything, and you're probably not qualified to design it anyway. Just explain what you want it to do. If you can't even do that easily, you're overthinking.

Advice for the developer: lead the development process, it's your job. See above. Your client is most likely a layman, with no understanding of how software is designed. Worse, decades of childish portrayals in the media have created the impression that it's some kind of magic. Do your best to educate, ask the right questions and generally guide things along; that can go a long way.

Development

Advice for the client: don't vanish into a black hole until the deadline. You may think the developer is some kind of assembly line cranking out the 937,546th identical car, but this is not so. If he could have reused existing software, it would all have been done in 5 minutes. The whole reason he's building from scratch is that your project is -- to a degree -- unlike any other that came before. And that means he needs your feedback. So watch your communication channels. Answer e-mail, check the previews and mockups you receive and generally be there.

Advice for the developer: too much communication is better than none. Keep in mind that the client can't read your mind any more than you can read his. So take the time at the end of each day to send e-mail explaining your progress, highlighting problem spots and asking for specific feedback. In the long term, it will benefit you at least as much as it does the client, by minimizing delays and misunderstandings.

Wrapping up

A software development project is only "done" when you pull the plug. This is doubly true on the Web, where every little change instantly reaches all visitors of a particular site, and every little change can have a disproportionate effect. And since you can't predict the future anyway, a contract saying "payment will be done after delivery of the finished project" is a recipe for disaster (possibly of the legal kind). You'll need to agree on some clearly defined milestones, but! that's not easy either, as things may change along the way. Be flexible yet focused. What was the project supposed to achieve, again?

General advice

Be respectful to each other.

That should be obvious, but it's surprising how many people forget this most basic of rules.

Developer, remember that the client worked hard for those money he's willing to pay you. It's only natural to expect some value in return. Also, he's not an idiot; he's just an expert in other things than you.

Client, remember that the developer has years and years of study and experience behind him; he's not your servant, nor a menial worker. He's a highly skilled expert and you need him, or someone else just like him.

There you go. You should be able to start off the right foot now.