Jason Leveille's Blog

Anyone who works in web design and development is familiar with spending a lot of time implementing client requests: modify this photo, change this footer text, add this navigation item, remove this link, etc.  Knowing this, I try to think about the decisions I’m making while putting together a template or writing code.  I often ask myself if the decision I’m currently making will impact maintenance later on.

Poor decisions during development/implementation lead to poor decisions during maintenance. (via Twitter)

The quote above could be reworded to: “Poor decisions during development/implementation lead to more difficult maintenance later on”.  I never claim to be perfect.  I know I make mistakes and I try to learn from those mistakes.  I try not to judge the work of others, but sometimes it is ok to be judgmental.  Sometimes it is ok to speak out against poor decisions.

The Edit Request

Today I was asked to remove a link from a navigation list.

Removing the Link

At this point I realized this template builder had achieved the button effect using one solid image.  I crossed my fingers and hoped that the image was a transparent PNG.

The Solid Background Image - a JPEG

The problem here is that the background behind the buttons is a patterned background.  Of course, any time you put a transparent gradient over a patterned background you’re going to have your work cut out for you.

Breaking the Maintenance Budget

If  client asks me to remove a link from their navigation, the last thing I want to do is charge them for 2 hours.  In the example above, we settled on an alternate link to replace the one we were removing, however had I rebuilt this navigation, even 2 hours would probably not have been enough time.  I would have had to:

• Recut the images (likely for a sliding doors implementation)
• Reworked the CSS
• Tested in various browsers

Thankfully, and without a hint of the technical underpinnings, we were able to convince the client that replacing the link (instead of removing) was the better approach.  Typically this kind of implementation is a window into a flawed template build.  One that will only cause problems as time goes by.  Decisions such as the one above are a source of major frustration when the maintenance man comes calling.  Without asking the simple question, “how will this affect maintenance”, you could be breaking the maintenance budget.  In the case above, we would have had to have eaten the additional cost to rework the navigation, or risked the potential of losing credibility with our client.  Neither is a good choice as far as I’m concerned.