During the development of a project, you’ll repeatedly be faced with situations where there are multiple solutions to a problem. One choice is to create a robust answer that is reliable and will adapt well to the changing needs of the customer for the foreseeable future. Another option is a design that addresses the current needs of the system, but may not address variations that could appear down the road. This second option is frequently quicker to implement.

In truth this is a gross oversimplification. Instead of these two polar extremes, there are a lot of shades of grey in which you have a trade off between a system that is robust and a system that is easy to create. Ultimately you need to respond to the needs of your customer. If you find yourself working on a project where the most important factor is the up front cost, design a site that meets the specification as inexpensively (read: quickly) as possible.

I’ve found that most customers are willing to spend a little more (…not a lot more!) for a site that won’t need to be overhauled in six months. When I’m figuring out what kind of trade off to make between designing fast and designing robust, I always consider the fact that I don’t want any of my work to be the weak link as the customer’s business or organization grows.

I just realized the picture I’m painting is of giant design decisions that mean the difference between a project taking a week and a month. I make these same choices on a much smaller scale throughout the project.

Let’s take a basic contact form as an example. It takes very little to make a contact form functional. Accept the form variables, generate an email to the site owner, and thank the visitor. Next.

Hold on a second. What if the mail fails to send? Did you display a message to the visitor that the mail couldn’t be sent? It doesn’t take much time to check that the message was successful and notify the user of any failure. This example is pretty simple, but it does illustrate the point, right?

You can also take steps to minimize the amount of extra time the robust solution takes. In the case of the contact form, I have a “template” that I start with and then customize for the individual site. I wrote a lot of error checking and data validation code into the template. I only had to write it once, but it shows up in the contact forms of all the sites I design.

I’ve gone off on a tangent, but my point is that you can save yourself time in the long run by taking some extra care up front. If the contact form breaks in a few months, you can bet the customer is going to come to you expecting an explanation and a quick fix. It’s nice to have recurring contact with the customer so you have the opportunity to drum up new projects, but don’t expect much interest if the last bit of code you wrote for them is broken.

I’ve observed an interesting phenomenon as I’ve designed sites over the years. The original specification I’ve been given by a customer always evolves some during the development cycle. When I go with robust solutions, I can usually quickly adapt the work I’ve already done to meet the new requirements. When I’ve tried to get by with a quick solution, it usually isn’t flexible enough to address the changes that occur even before I’ve finished working on the project.

filed under: Project Management