Post Ad Area

Monday, September 13, 2010

What Is The Worst Design or Programming Mistake You’ve Ever Made?

Mistakes are made every day in the design and development world. It’s nothing to be ashamed of; it happens. In fact, mistakes are one of the most powerful learning tools at our disposal. Our mistakes impart important lessons that we carry with us as we continue to hone our skill set. Own your mistakes. Never shy away from them; they are the milestones in our development.
So often we view mistakes negatively and let them get us down. We believe they indicate failure and that our otherwise perfect record will be forever marred. No one is perfect; we all make mistakes. They indicate failure only if we fail to learn from them.

How often have you stayed late, trying to get something done and did some embarrassing mistake instead? We can learn from our mistakes and mistakes of our colleagues. Image credit
The online design and development community is a wonderful resource in this respect. Not only are members open about their mistakes, they share their experiences as learning opportunities for others — this is helpful for those of us who have not yet suffered through the same bumps in the road.
With this in mind, we turned again to our Twitter followers and Facebook fans to find out about the worst design or programming mistakes they have ever made. Now we share them with you, our readers, so that we can all learn from them and avoid making the same mistakes.

Related Posts

[Offtopic: by the way, did you know that there is a Smashing eBook Series? Book #1 is Professional Web Design, 242 pages for just $9,90.]

Bait And Switch

The first common mistake we should learn from — and which several of our followers have had to face — is the old bait and switch. It occurs across the spectrum, for the newb and the accomplished professional, because it’s an easy mistake to make as the working hours add up. What is the bait and switch? It happens when you’re working on one version of a website or project and, at some point during the tinkering, you accidentally switch it for the active website or project before it’s ready.
When we’re in a constant back-and-forth workflow, getting mixed up is easy, at which point the bait and switch can happen. And it causes all kinds of chaos and headaches. Awareness and caution are needed to prevent this error from being part of your personal experience. Before you finalize changes or processes, be sure you’re working with the right file and uploading to the correct location. This isn’t a sure-fire prevention plan, but it will certainly improve your chances.

What Our Followers Said

  • “I accidentally put a half-finished (with massive broken bits) update of a website over top of the current live one without a back-up.”
  • “I sent $10,000 worth of product to a customer while testing an ordering portal.”
  • “I deleted an actual repository instead of a working copy. #svn”
  • “Worst programming mistake: editing off a live server and then uploading an old version of the website. All files lost!”
  • “Sat on the development FTP for half an hour, being mad that the live website wouldn’t update!”
  • “Moved the entire directory of websites on a live server into a different folder, then lost it or deleted the in-house CMS”
  • “Programming mistake: writing data to the wrong database.”
  • “Uploading to the dev website FTP and wondering why the live website wasn’t changing, which sent me around the bend in the process!”

Falling Behind On Back-Ups

Given that back-up-related mistakes usually come to light once you realize you’ve just pulled a bait and switch, we’ll tackle these next. Problems with back-up files are common in the design and development community, and they are openly lamented. For some reason, though, many of us still find ourselves panicked when we realize we have no current back-ups of the project we’re working on. And it usually hits us just after we lose the active version of the project and need it replaced.
We can take steps to save elements of our work and prevent episodes like this from becoming remorseful blog posts. You can be either low-tech or high-tech when you address this potential problem, but you need to do something. It could be as simple as making a list of details to check daily, and backing up data could be the final step. Alternatively, you could pay for an automated back-up service that guarantees completion of the task. There are several options, each with pros and cons, so find one that works for you and implement it post-haste.

What Our Followers Said

  • “I moved a dynamic, CMS-contained website across to a new server. Forgot to back up, then deleted templates in the process. D’oh!”
  • “Mistake: not backing up a compiled Flash slideshow, replacing it, then realizing the new version was completely broken.”

Measure Once, Cut Twice

The next mistake we’ll cover happens fairly often. For any number of reasons, we end up measuring once and cutting twice, so to speak. The measurements we work with vary greatly from project to project and from Web to print, so we need to be alert to what we are sizing and aiming for. Sometimes it isn’t so much the measurements as it is the content that requires a re-cut.

Often calculations, measurements and the concept phase need more time than expected. Turning off the computer and getting back to the sketch board or a notebook is often very useful to avoid mistakes. Image credit
Chalk it up to being overzealous or getting sloppy in our work as we push toward deadlines. If these are the reasons for our re-cuts, prevention is easy: just avoid those things… which is easier said than done. Still, if we mind our p’s and q’s and double-check everything before submitting it, our chances of embarrassment decrease. Follow the carpenter’s old rule of thumb, “Measure twice, cut once” — it benefits us designers and developers, too.

What Our Followers Said

  • “Mistake: having 20,000 cards printed that didn’t fit into a lanyard card holder”
  • “Got my colleague’s phone number wrong on her business card… We ordered 2,000.”
  • “This isn’t really a programming mistake, but the most embarrassing mistake I’ve made in Web design was buying a domain name that had the client’s name in it — but part of the name was wrong. Good thing domains are cheap!”
  • “I managed to drop an ‘m’ off ‘millimeters’ in InDesign. Ended up with an 88-meter-wide business card. Schoolboy!”
  • “I think most of us have experienced the horror of hitting ‘Send’ on an e-blast, only to quickly realize it’s wrong.”
  • “Mistake: when I post something and then two weeks later or more, I find out something’s wrong with it.”
  • “A couple of years back, I made a beginner’s design mistake with print: envelopes and paper didn’t match.”
  • “Sent PDF to the printing house for 1000 leaflets. Received them and realized that the phone number was wrong. Then, sent corrected PDF, received leaflets and realized that the wrong PDF was sent. We had 1000 useless leaflets with the right number but with the ‘iStockphoto’ watermark on every (lo-res) picture. Third time it was OK.”
  • “I dropped an ‘L’ from the word ‘public’ in a school prospectus (and website). Honest mistake!”

Miscommunicate Expectations

Another problem encountered by designers and developers that you can learn from before encountering it is a breakdown of communication with a client or boss. Many of us let things become unclear or slip by, which makes us unsure whether everyone involved in a project is on the same page. Usually this is caused by a lack of confidence in ourselves or fear that asking for clarification would reflect poorly on us. Whatever the reason, we decide not to revisit the issue and instead proceed with a shaky understanding of what we’re supposed to do.
Every time we communicate with our boss or client, we open ourselves up to the possibility that one or two ideas might get lost in translation. We should be as clear and concise as possible in our discussions so that work stays on track… at least on our end — we can’t control others. If we’re dealing with someone who is unfamiliar with the design and development field, understanding what they’re asking for can be tricky. Take notes, and go over them with clients at the end of meetings so that everyone understands where things stand. Good notes prevent communication blunders.

What Our Followers Said

  • “I underestimated the amount of content that two different clients wanted. Not a clear picture from the start.”
  • “For my part, I must say, not reading a ticket well enough and spending two days coding something that wasn’t asked for. Over-enthusiastic FTW!”
  • Emily B.: “My mistake was telling my current employer than I have some experience in Web design (meaning HTML and some CSS); now it’s part of my job to learn how to code ASP and maintain and redesign our entire e-commerce website. Ugh. I’m a print designer!”
  • “I’m in the same situation as Emily. Job description and interview included ‘some Web,’ and now I’m trying to learn PHP and run a full searchable retailer list for my company! Thank God for online tutorials!”

Careless Coding

When it comes to coding, we can easily drop the ball. Coding is an in-depth process, in which many different layers are stacked on top of each other, and one can get lost in it. This is one reason why developers comment in their code: so that they leave trails of breadcrumbs throughout their projects. This is a good habit to form, but sometimes it leads to an embarrassing faux pas or frustrating hours of rebuilding, as revealed by our followers.
With just one misfired keystroke, a project can go from a coder’s dream to a virtual nightmare, with no perceptible way out. As if that’s not enough, our coding comments can bite us in the back end, especially if we’ve thrown some nonsensical, fun or unprofessional bits into the code and forgot to remove them. We need to be mindful as we code and avoid distractions as much as possible to avoid burying mistakes so deep that they reveal themselves only after hours of careful combing. Also, take one last look through your comments to be sure you’re not leaving something that you’d rather others not see.

What Our Followers Said

  • “I left some profanity in a client’s HTML once while testing text-indent (off-screen position). Very, very embarrassing.”
  • “Accidentally leaving things like ‘Mooooo’ and ‘Baaaaa’ in code that has gone live!”
  • “I used to write haiku in my code to mark my place, and I think I forgot a few out there somewhere… not anymore!”
  • “I once did (as root) `rm -rf tmp /` instead of `rm -rf tmp/` on a Friday afternoon. Painful weekend.”
  • “A typical one: Using = instead of == in an if statement. Always takes quite some time to figure out.”
  • “Typed rm -rf .* on the server. @wsttn wasn’t happy when I deleted everything.”
  • “Using a body * { text-align: center; } on a log-in form, but accidentally placing it in the default style sheet instead of the specific log-in style sheet. Our largest customer didn’t like it when it went live.”
  • “I removed the ID from the ‘Submit payment’ button, and the website failed to take bookings for six hours. Lost £20,000.”
  • “Forgot the where clause when testing SQL to a user table. No fun, I tell ya!”

Forgetting The Filler

Sometimes we forget to redact our coding comments and leave in an embarrassing tidbit or two. There are also times when we accidentally leave in filler content. That’s not necessarily a problem unless the client does not recognize it as filler, because then they might not remove it either. Remember that clients, especially the less technically savvy ones, are probably extremely paranoid about deleting anything, so any filler you forget to pull will inevitably be published to the masses.
Again, it comes down to vigilance. We can’t stress enough — on top of all the other stresses in the design and development field — the importance of double- and triple-checking all of these elements before labeling anything as complete. Certainly do this before turning anything over to the client. Making a generic checklist for every project you take on will help you avoid these mistakes. Remind yourself somehow to watch for elements that tend to slip through the cracks.

What Our Followers Said

  • “Forgetting to remove nonsense words (used for testing) in an assignment and losing marks. Otherwise, perfect code.”
  • “Two words: dummy data. Strictly ‘Lorem Ipsum’ ever since.”
  • “One time I left an unkind phrase about a client in the comments, and they found it later on.”

Wrong Tool For The Job

The last mistake we’ll discuss in depth usually occurs early on in our experience in the design and development field: using the wrong tool for the job. It does happen, and more often than we’d like. When you’re unfamiliar with a field, you’ll sometimes use the wrong platform yet believe you’re on solid ground. At some point, you find out that the program, a supposed godsend, is not compatible with your client’s program or the program of others involved in the project.
Setup in What Is The Worst Design or Programming Mistake Youve Ever Made?
Wrong tools doesn’t necessarily mean your coding or designing applications, it also can mean a wrong environment or computer setup. On the photo above, the setup looks solid and well-organized. Image credit.
Communication can assist in this area, though not as much as research. Find out from your client exactly where the project is going, and contact them yourself to ensure that files will be delivered in the proper format. You can leave this to the client, but you are responsible for ensuring compatibility, so it’s best not to leave it to someone else. Also, as you transition to new areas, research the tools of the trade to avoid making this mistake.

What Our Followers Said

  • “I tried to deliver my very first program for Notts County FC to the printers in MS Publisher. I cringe even now.”
  • “The first Photoshop website I ever did was a sliced PSD with all of the content in images… That was back in 1999/2000.”
  • “Using Drupal to do ‘quick ’n’ dirty’ websites. They were dirty, but they sure weren’t quick.”
  • “Designing a database app: rather than de-normalizing data, adding/removing table columns on the fly. Long time ago!”
  • “Hard-coding a navigation across 10 pages instead of using an include. Was new to Web dev at the time.”
  • “Depending on an external source for data and, because that crashed, our website crashed. Almost cost me my job.”

More Mistakes To Learn From

Below are several more community-contributed pearls of wisdom that we can learn from. We’d like to thank our dedicated followers who revealed their biggest mistakes so that we could benefit from their toil and trouble.
  • “Mistake: severely undercharging for a massive job. My very first freelancing job. Was not worth the time and effort!”
  • “There was a time in the ’90s when I thought Papyrus was beautiful. *Hangs head in shame*”
  • “I once created an iteration of a logo using Comic Sans, and it was chosen! I’m not proud, but I was young and naive at the time.”
  • “Used Comic Sans for something serious.”
  • “How about 90,000 alert emails sent to four people over one weekend (myself, a colleague and website owners) = 360,000 emails.”
  • “Deleted the shopping cart table from a live website instead of deleting one of the records in the table.”
  • “The worst programming mistake I made was to develop an admin area with cookies only (without other security systems).”

Start typing and press Enter to search