Fixing Bugs -or- Why 5 minutes Sometimes Means 2 hours

I’ll try to keep this brief, as I’m sure you all probably realized this already. Even so, it’s always a good reminder and will help keep developers and non-developers on speaking terms.

I’ve got a simple analogy for you as to why some (many) things take longer to develop than developers initially estimate and, more importantly, why we perpetually believe it will only be “just 5 more minutes” as we continue to debug.

The leaky sink.

Now, a leaky faucet is presumably simple fix. You will usually have a good idea where the problem is coming from because you can clearly see where the water is leaking, but not always. Most leaks can be fixed with what you already have around the house, but sometimes you have to go out an get new parts. Many times you’ll already know how to fix it, but now and again you’ll need to do a bit of research. Lastly, once in a great while you’ll need to call in an expert, because the problem either wasn’t what you expected OR it becomes too big for you to quickly do by yourself.

Sometimes it’s a simple problem… (5min or less)

The best scenario. This is when you didn’t close the tap all the way, or something has come just a little loose. In programming, this would be a typo or a simple logic error. No big deal, it’s already fixed.

Sometimes it’s a different problem… (5min, x2)

This one is annoying. You thought it was a problem with the faucet, but later found out it was a problem with the tap. You’ve already spent 5min working on the faucet, and now realize you need to spend another 5min on the tap. This happens a LOT in programming.

Sometimes it’s multiple problems… (5min, x2, x2, x2)

Now you’re really frustrated. You looked at the faucet and saw it wasn’t there, then you spent 5min on the tap and the leak still exists. Now as you look more closely you see there’s actually another (two, three, four) problems happening underneath the sink. Or, worse, because you fixed one problem you’ve actually created a problem elsewhere (without the steady leak, now a pressure buildup has busted a pipe. $#!&).

Sometimes there’s a false positive… (5min, x2 …. wait 30min, try again)

The leak has stopped! …temporarily, until you or someone else tries to use the faucet again. You’ve spent your 5 (10, 15) minutes fixing what you thought was the problem, and now the problem is back again. In programming, this is especially troubling because now you’re not sure if it’s just a caching issue or something else entirely.

Sometimes there is no problem… (30min for nothing, FML)

There wasn’t a leak, you (or someone else) just splashed some water up behind the sink. In programming, you’ve spent the last 30 minutes chasing a bug that doesn’t exist. Do not pass go, do not collect $200.

Hang on, just 5 more minutes…

Next time a developer tells you “Just 5 more minutes” and they’re wrong, remind yourself that they’re not lying and they’re not bad at estimating (and no, they don’t hate you), they’ve just encountered a new or different (or additional) problem than they set out to fix 5 minutes ago.

Regarding Your Logo

It’s no secret that I appreciate a really well-made logo and so, having designed a few myself, I think I am adequately qualified to adress the topic with some authority. Before I get too far, I want to say that I’ve outsourced many of these ideas to other thinkers who are smarter than myself and that you should read their articles entirely if you want to get the full value of this message.

To all of you who think your logo really matters, I want to tell you up front: your logo doesn’t matter. According to Mark Bixby,

“Your logo is only one very small part of building a successful brand. Its design is minimal in making your promise match your customers’ experience (read: branding). Design is an invaluable tool in communicating who you are, what you do, and why it matters. But if you can’t articulate these things yourself, design cannot do it for you.”

Going further on branding, Seth Godin reiterates that your logo is not your brand, concluding

“Take the time and money and effort you’d put into an expensive logo and put them into creating a product and experience and story that people remember instead.”

Now, that isn’t to say that you should go looking for the least expensive logo you can find. Far from it! In fact, that’s exactly how NOT to design a logo. Seeking out services that encourage design competition and crowd sourcing only hurt your business and the design industry. In fact, there have been entire campaigns created around abolishing speculative work like this. Furthermore, if you think “I’ll know it when I see it”, I just want to be the second to let you know, you’re wrong.

If you’re at all serious about your business, at all interested in improving the lives of your clients/customers (as you should be, that’s the only reason to be IN business), then do yourselves both a service and do things right.

Understand what it is that you do (or want to do) and place the interests of others before your own. Only work with a credible designer who is going to work alongside you to understand why your business exists and why anyone else should care. If they’re good at what they do they’ll have a top secret process they follow in order to produce quality work and fulfill your needs.

To summarize: your logo should only speak for you when you’re not there to speak for yourself. The brand that you’re working so hard to build can only be built on fulfilled promises and expectations, not outstanding design. So, let your business speak for itself and only use your logo as a small identifier from whom the message is sent.