Managing Towards Failure


I used to enjoy racing cars. I was never very good at it, but that never stopped me from being passionate about it. In an effort to get better at driving insanely powerful cars I would take courses from professional drivers / instructors.

One day an instructor told me something that stuck with me. During a particularly frustrating moment for him, as we were spinning into the infield yet again, he said “You always go where you look, there are no exceptions!” As it turns out, every time I approached this particular corner I would focus my eyes on the grass infield rather than the pavement. As a result, my hands would subconsciously steer the car ever so slightly too far into the turn. When you’re moving at a car at an extremely high rate of speed, “ever so slightly” makes a big difference.

The next time through the corner I made a concerted effort to stare at the pavement instead of the grass. It was weird, because I actually couldn’t see the grass when I did this. Guess what. I made it through the corner. Of course, on the next corner I found the infield again but that’s for another story.


There’s a term I’ve developed over my years of watching management, I call it “Managing Towards Failure”.

It’s something you see just about everywhere you go and as far as I can tell it’s a management style that has a roughly 0% chance of success.

In summary, managing towards failure is the practice of making management decisions based on failures. Focusing in on failure, just like looking at the grass infield, steers you towards… you guessed it, failures.

In technical management I’ve seen the following all-too-common example:

A team of 10 developers are tasked with creating a medium-sized product with a 6 month timeline. In the first two months eight of the developers make estimates with around 80% accuracy. Two of the developers, however, trend closer to a 20% accuracy. As time goes on, management continually looks to improve the team’s overall estimating accuracy by coming up with ways to mitigate the two less accurate developers. Often, this mitigation takes the form of added “process”.

New process elements are designed specifically to keep the under-performing developers from failing. Unfortunately, as is normal with “process”, all of the other developers (who were accurate with their estimates in the first place) will be held to these same standards.

As the project gets into the final stretch developers begin struggling to get all of their paperwork and development done. Management gets increasingly frustrated with the developers for not delivering results; developers get increasingly frustrated with management for imposing more controls that limit the creativity and productivity.

Once the project shows up late or failed altogether, more mitigating process is added at the project planning level. Next time there’s a project of similar size, the pre-existing process that was designed around the worst developers remains. The next project adds its own failures, the cycle continues.

Eventually management focuses on why everything fails and adds more measures to prevent failure rather than recognizing the heroes who save what can be saved. All the while the original two developers who couldn’t estimate in the first place got no better at estimating, they simply learned to do paperwork.

The entire team was held to the standard of the worst performers and ultimately no one performed well. No one on the team got better at anything (except maybe paperwork). The original weak performers never got better at estimating, they may appear better because the rest of the team was drug down to their level, but they never actually improved. Management’s focus on failures has created more failures.

The Root Issue

I feel like the root issue speaks towards today’s prevailing management culture. Most often, the management I’ve worked with has been terrified of catastrophe. The higher level the manager has achieved, the more pronounced their fear of things going horribly awry. Their fear of failure is far stronger than their desire to innovate. If your mandate is to “avoid catastrophic failure” then how successful can you be? It’s important to remember that “didn’t go horribly awry” is not equal to “great success” in any form. Ever.

The Solution

The solution is something that management-types have been preaching for years but not really following. Reward success, don’t punish well-intentioned failures. If you focus on success and high performance, you’ll get more success and high performance. As a manager it is, by far, the more difficult road but the results have been proven time and time again. Find disciplined managers who don’t fear failure and trust them to do an amazing job. Because in the end, if you fear failure even a little it will choke out the bravado you need to be a great success.


Welcome to the real world, techie!


First, here’s the article that sparked this post. I’ll wait while you take a look at it.

The comments on that article show that most of the folks who read that article and decided to comment did so in support of Shay Pierce, the former employee who spoke out against the purchasing company.

I’ve dealt with so many issues between management and developers which are rooted in issues just like this one. A developer wants to stand on principle and claim that things should be a certain way. Management wants to make money. The two goals find the parties at odds and management writes the developer off as a “diva” while the developer writes management off as inept and uncaring. It’s too common and it poisons the water on both sides of the fence.

My note to developers: If you want to remain principled, stay in academia. The real world is a tough place that operates on structure and the unending chase for money. In fact, that person chasing the money is the only one with enough of it to pay you what you think you’re worth. So don’t get all high and mighty, demanding more money in your paycheck while at the same time criticizing those chasing that money for doing it incorrectly. You don’t want management coming by your desk telling you how to solve tech problems, do you?

In this case, Shay Pierce found himself working at a company with 40 people. Someone wanted to buy that company and his management swindled a deal for $30 million in retention bonuses for employees. Let’s think about that math for a moment. $30 million to spread around 40 employees. Any way you slice it the company was a success on a product that isn’t really revolutionary.

My note to management: Don’t get too worked up over the divas among developers. There are diva managers too. In fact, they’re probably so busy kissing your ass that you have no idea that they’re alienating everyone in your company who actually does something that you can sell. Developers like to think that they’re working for a higher cause, particularly those new to the game. They still believe in changing the world one line of code at a time and forget that they should actually work on keeping the lights on one line of code at a time instead. Give your developers some autonomy, set aside some time for them to do what they want to do and pay them for it. Chances are they’ll blow your mind. They know things you don’t know and they see things differently than you do, don’t write the quiet ones off and never manage towards failure.

In this case Dan Porter found himself with an employee who didn’t agree with the direction he was taking. The best approach is “Your opinion has been noted and will be considered.” Dan went bananas and kind of made a jerk of himself. This has completely overshadowed the fact that he organized and settled an amazing deal for his 40 employees.

If you want a truly successful tech company you’re going to have to figure out how to get the working techies and management talking about the same thing in the same language. Until you do, every day will be a war.

ISO Recorder – A Must Have PowerTool


As part of my parting duties for a job I’m leaving I have been asked to set up a virtual environment with all of the projects requiring older platforms. This is something most developers have a virtual machine for, but sharing one across the company makes a lot more sense. It’s something we had intended to do for some time but just never got around to.

In doing this, I had to consult our software stockpile to find the old CDs of Visual Studio 2002 (it was originally just called Visual Studio .NET). Since my new-format MSDN subscription doesn’t allow me to download the ISOs of this directly, I was tasked with create an image of each of the CDs so they could easily be mounted on the server (there’s no physical optical drive).

Creating an ISO should be something that Windows has native support for now, but it doesn’t. So I set about finding the best easy, quick and free solution I could.

I came up with ISO Recorder.

It’s quick to install, it’s free, it doesn’t require a reboot and it makes the process as easy as selecting the drive, right clicking and creating an ISO. It’s rare nowadays that we find such laser-beam focus in software without bloated options. But this did exactly what I needed to do and did it quickly. For that, it gets a mention on my blog.

RockMelt – My new default browser


Part of my job requires that I install just about every browser available. Something they all have in common is that every… single… one of them continually asks if I would like for it to be my default browser. They try to make it so enticing, “Don’t you want me to be your default browser instead of that scamp over there? I’ll be good to you!” It never works.

After all, being my default browser isn’t an easy job. I demand things from my browser that most web surfers never even conceive of. When I click a link, I have to trust my default browser to jump into the task quickly, accurately and with impeccable stability. And I’m not talking about sometimes, I’m talking about ALL the time, every time.

For quite a while, Chrome has excelled at the task of being my default browser. I still use other browsers from time to time, but they just don’t seem to stack up to my needs like Chrome does.

Along came RockMelt.

For me, RockMelt evoked a stroke of genius by basing their browser on the Chromium platform (the same one that Chrome uses). I don’t know whether this was a matter of necessity, function or preference but it’s what ended up making my decision for me. It’s like Chrome++. If you’re like me and you like pinned tabs, Chrome Apps and dozens of other awesome Chrome features you don’t have to lose any of them to change browsers and get some cool new social functionality.

So what exactly is RockMelt? From their web site:

RockMelt is re-imagining your online experience by creating a new web browser that makes it easy to stay in touch with friends, search online, and get updates from your favorite websites.

What that means to you is that it’s a fast, stable browser that integrates directly with Facebook and Twitter.

The best way to see what I’m talking about is to watch the RockMelt promo video, I’ll catch you afterwards:

After a week of using RockMelt as my default browser, here’s some things I’m really digging:

  • The sidebars allow me to have my social media items available, but not in the way
  • The ability to add ANY RSS feed to the sidebar
  • The ability to quickly and easily share whatever web page I’m looking at with my Twitter and Facebook networks
  • The sidebars are easily hidden with simple keyboard shortcuts (CTRL+SHIFT+[ and CTRL+SHIFT+])
  • It’s Chrome (which I love) just better

And some things I’m not so jazzed about:

  • No apparent support for Twitter DM (really?)
  • Twitter mentions are not noted on the icon, you have to open the feed, click the sidebar icon and then load mentions separately… Changing the color of the message notification if you had mentions would be a nice touch
  • There doesn’t seem to be a way to share something with all networks at once

Want in on it? You either need to be invited or you need to get in on their beta program, which you can do over on their web site (by connecting with them on Facebook).

Making simplyScroll Scroll Left-to-Right


The folks over at Logicbox have written a nifty little jQuery plugin called “simplyScroll” that allows you to easily and seamlessly scroll through a collection of images with little effort.  This is a great way to avoid making a Flash animation to accomplish the same task and… it works on the iPhone. We needed to use it to make a looped, seamless scrolling header for a site on the quick.

One caveat, however, it doesn’t have an easy built-in way to scroll in the opposite direction of the default (ie. “Backwards”) which is what our client wanted (at the last minute). We emailed the author and were told that it would take “quite a lot” of changes to make this happen.  The client was breathing down our necks on the tight deadline and we were running out of time, so I jumped in with both feet to hack the thing.

Now I realize this isn’t the “right” way to do it. This is an admitted hack because I didn’t have time to go back and do it correctly. Maybe the original plugin’s author will add the correct functionality or maybe I’ll have time to do it “right” and send it to them. But for now, this will absolutely work.

First, change the default function called when you use the “auto” functionality (line 152):


- becomes -


Now tell the position reset functionality that the default position is the sum of the width of all of your elements (line 219):

this.$clip[0].scrollLeft = 0;

- becomes -

this.$clip[0].scrollLeft = 5904;

The number “5904″ is just the added up width of every element we ended up having in the animation.

It’s that easy!

jQuery, mootools and NextGEN Smooth Gallery – A tale of failure


Maybe I’m behind the ball on this, but I’ve never tried using multiple JavaScript frameworks on the same page.  I’m the kind of developer who likes to stick to a framework and then make it do what I need it to do.  Sure, all of the major frameworks have some unique and useful plugins, but cutting down on load time and complexity usually trumps any small amount of extra functionality I may gain from using multiple frameworks.

Today, however, I was asked to diagnose an issue with a client’s WordPress site.  All of a sudden the following JavaScript error had started popping up:

Error Console

The evidence

The folks who had been working with the site were at a loss as to why this would happen, so I started digging in.

After some digging and looking at the source code for the page I noticed that not only was jQuery being called twice (eesh) but mootools was being called as well.  The calls weren’t coming from the custom template that the site was using, they were coming from [dun dun dunnnn] INSIDE THE WORDPRESS CODE ITSELF!

After a little digging, I discovered that a Gallery plugin the client was using, NextGEN Smooth Gallery, was loading mootools to do some cool displays and animations for one of their image galleries.  The downside is that the call to mootools was on every page.

NextGEN Smooth Gallery

The culprit

You see… both jQuery and mootools like to use the dollar sign ($) to denote shorthand for their calls.  While this can be pretty easily overcome manually by calling jQuery directly (using jQuery.yada) any plugins that you have for one of the specific frameworks will very likely use the shorthand notation somewhere in the code.  If they do, you’re screwed.

So let my couple of hours of research serve as a warning to those would be framework cross-mojinators out there.  It’s not worth it!

Scammers: Way better with Facebook


I got a good chuckle out of a message I recently got on Facebook.  The message follows:


My name is Barrister Donald Gogo from Togo personal attorney to late Mr.B.A.Garvich. I am contacting you in respect of Twenty Million USD left behind by late Mr. Basel Garvich, who lost his life and family (wife & daughter) in auto crash in 2005. He has no next of kin and an heir is needed urgently who has same family name hence I have contacted you and to present you as heir to his estate so that the funds can be credited to your bank account as heir/relation.

I have tried all that I could to locate the immediate family but abortive. I have 14 days to provide the heir otherwise the funds will be declared unserviceable and confiscated. This is highly confidential, Please send your reply to, Tel:+2289798177.

I await your response for more detailed information.

Best regards,
Donald Gogo.

The fact that these guys have figured out how to fake a relative with an exact last name is a pretty impressive advance from the “I’m the deposed prince of Nigeria” scams that we’ve seen for years.  That they’re able to use Facebook to accurately target the name is going to get a new crew of people caught up in scams.

Now obviously, I have an incredibly rare last name.  If you meet someone with the same last name we ARE related.  And if there had been one of us who was worth $20m+ who had died, along with their family, in a horrific car accident I would know about it.  But not everyone is: A) used to seeing these things; B) savvy enough to realize it’s a scam; C) attentive enough to note that a “lawyer” is sending a message with many obvious grammatical errors.

It’s our responsibility as the technologically savvy to make sure our family and friends are at least in the know, if we can’t actually protect them.  Pass this along and make sure none of your favorite people fall for the scam.

Consolidating Google Accounts


I’ve been using the web and email for around 16 years now.  Over time I’ve been through a LOT of different services and so far, I have to say that Google has impressed me more than anyone ever by providing great, free services like Google Apps For Your Domain.  One of the downfalls of Google Apps has always been that you didn’t get access to the other cool Google services (like Google Voice and Google Reader, for example) unless you had a standard Google Account (GMail).  Well that’s no longer the case, Google has announced that you can now start consolidating accounts.  And consolidate I shall!  Along the way I’m going to write up how I accomplished things and any pitfalls I run into.

The Goals

I’ve got several goals that I’ll outline below, but there’s really only one… and that is to greatly simplify my life.  But working up to that, we have:

  • Consolidate all of my email accounts [7], calendars [10] and address books [2] down to two, a work and personal account
  • Lose NO data of any kind
  • Have the ability to manage all accounts from wherever I am via iPhone or the web
  • Do NOT lose the ability to communicate through all of my separate accounts easily (if someone is looking for me in regards to my band I don’t want to send them email from my work account, for example)
  • Get and manage all email quickly and easily
  • Start using more Google services than I was before by using one account for all of them

The Moving Parts

The services I’m dealing with break down like this:

  • Email – 1 GMail account, 4 Google Apps accounts, 1 Exchange account, 1 POP account
  • Calendars – 9 Google Calendars, 1 Exchange calendar
  • Contacts – 1 Google Apps Address Book, 1 Exchange address book

As you can see I’ve done a bit of work previously by getting most of my calendars and contacts moved over to the cloud via Google.  You may have to do some extra work if you haven’t already started that process.

Step 1 – Consolidating Email

I knew the biggest job was going to be getting email consolidated so that’s where I started.  I had a little bit of a unique situation in that I wanted to create a new, more friendly account for myself using one of my domains hosted through Google Apps.  The reason for this is that once I have this account associated with various Google services I don’t want it to say “” – I want it to say “”.  So I created a completely fresh account to work with.

Transferring Email From One Google Account To Another

In my case I wanted the new account to have ALL of my old emails.  If it’s going to be my primary account I want to be able to quickly search and find old emails when I need them.  This step takes a long time (it ended up taking 2 days for me) to complete, so I’m listing some work to do up front to cut down on the time as much as possible.

  1. Clean up your existing account by deleting spam, trash and any imap generated junk mail/spam/trash folders.
  2. Get rid of any unnecessary messages you may have archived by searching for them and deleting them.  Even if you do this very well you will probably end up with a bunch of unwanted messages to sift through.
  3. Enable POP retrieval of your email in your Google account
    1. Go to Settings > Forwarding and POP/IMAP
    2. Adjust the “POP Download” section to however you’re going to want it to work
    3. Repeat for every account that you want to retrieve all historical email from
  4. Set your new primary account to start retrieving email
    1. Go to Settings > Accounts
    2. In the “Get Mail From Other Accounts” section click “Add a mail account you own”
    3. Go through the Google verification process
    4. If you cleaned your old accounts up, you may want to automatically archive email retrieved from those accounts for now (obviously disable this after you’re done)
  5. Set up temporary filters.  If you have a bunch of messages flowing in now is the perfect time to set up some account filters which will automatically organize the incoming email for you.  An ounce of prevention saves a lot of character building down the road! ;)
  6. Monitor your progress.  These POP accounts have some logic built into them that dictates how often they retrieve email so if you have a ton of email like I did you probably will have to babysit the process.  You can re-initiate a check by editing the entry for the POP account and saving it.

Once you have all of your old email moved over, archived and ready to go it’s time to start flipping switches!

Setting Up Sending

Before you’re quite ready to receive email on your new account you need to make sure that when you send email it looks like it’s coming from the right person.  Google makes this (like everything else) pretty straightfoward.

  1. Go to Settings > Accounts
  2. In the “Send mail as” section click on “Add another email address you own”
  3. Go through the verification process

In my case I wanted to set my account up so that whenever I hit “reply” the “from” field is the same as the one the original email was sent to.  In order to make that happen just check the radio button for “Reply from the same address the message was sent to” and make sure you save your changes.

Once you’re ready to send… you’re ready to receive!

Migrating To Your New Account

If you’re ready for all of your new emails to start coming to your new account you’ll want to set up forwarding from your old accounts.  You can do this as follows:

  1. Go to Settings > Forwarding and POP/IMAP
  2. Click “Add a forwarding address”
  3. Go through the verification process
  4. Set things up as you’d like them to work

Note that the email you get will have the original sender as the “from” address (not your account that you used to forward it) and will have the original “to” address (not necessarily the account you’re using to read it).  This is what allows you to send from the various addresses according to where the original email was sent.

Step 2 – Getting Services

This part is far easier than the previous section.  But you have to have access to administrate your domain on Google Apps in order to make it work, or your domain administrator has to be open to setting this up for you.

For Admins

  1. Log into the Google Apps domain admin account and click “Manage this domain” at the top
  2. Go to “Domain Settings” and make sure that “Automatically add new services when they become available” and “Enable pre-release features” are both checked
  3. Make sure that the Google Apps beta messages are addressed and enabled (if there are any)

For Users

  1. In your Google Apps mailbox, click on “More” at the top left
  2. Click “Even More”
  3. Go nuts!

Step 3 – Setting Up Your iPhone

There are two ways to set up your iPhone to access your Google mail account:

  • As Exchange – Allows email, calendar and contacts support
  • As GMail – Allows email and calendar support

One of my requirements is that all of this work happily on my iPhone.  I almost succeeded, but there is one thing you should know.  If you consolidate all of your accounts into one account, the account you consolidated to is the only one that you can send mail from on your iPhone.  This is important, in my case, because inevitably my iPhone ends up being my primary email client and while my accounts are all consolidated I need to be able to respond from whatever address the original sender was communicating with.  So this is a significant frustration, but there are a couple of workarounds:

  • You can set up imap accounts for all of your old accounts on your iPhone and then set them to never automatically check for email.  Then when you create an email you can define the “from” field.
  • You can use Google’s iPhone app to respond to email when you need to send it from a non-primary address.

How To Get Empathy To Connect To Google Apps Chat


So I’m doing more and more work on Linux these days and I’ve got an Ubuntu installation set up for that purpose.  Really it’s just a fun way for me to get a break from the Windows 7 world and develop in a new environment.  Anyhow… I ran into an issue with getting my Google Apps chat accounts working with Empathy.  I did some research online and didn’t come up with any solutions quickly, suggesting that the answer is harder to find than it should be!

Then I remembered that using other clients the Google certificate always gave a warning.  So, all you have to do is check “Ignore SSL certificate errors” and use the normal account setup beyond that and everything works flawlessly.  For reference, the normal account setup is:

Login ID: [your full e-mail address]

Encryption required (TLS/SSL): checked
Ignore SSL certificate errors: checked
Resource: [whatever you want it to be]
Priority: 0

Override server settings
Port: 5222

10 Ways To NOT Suck At Programming


Recently I wrote a therapeutic rant for myself, called “10 Ways To Suck At Programming“.  The article got syndicated to some link sharing sites and picked up quite a bit of traffic and comments.  The comments here on my site were, for the most part, nice.  Comments elsewhere were a mixed bag with many people saying the sarcastic nature of the post wasn’t helpful.  While I didn’t see it as sarcastic (after all, it was quite literally telling you how to suck), and even though I’ve written many, many helpful technical articles that did nothing but collect dust, I figured I would take a shot at offsetting my previous rant with real steps programmers can follow to make themselves better.

Obviously, this is not a comprehensive list and most experienced programmers should already be well versed in what’s here, but it’s a decent start for newbies and probably a worthwhile reminder to some of the more experienced.

… and it will be interesting to see if an article intended to be helpful gets as much traffic as a 20 minute rant. ;)

#10 Store settings in a configuration file

Configuration files are a necessity in today’s programming world.  With most applications connecting to databases, e-mail servers, file shares and other outside resources it’s imperative that a good programmer store any information that has a possibility to change outside of the release cycle of the application in a configuration file.  This will allow the application’s settings to be changed without having to recompile (retest, redeploy) the application.

It is important, however, not to overuse configuration files.  Some things belong, some things don’t; and experience is really the best way to know which is which.  You can ask yourself, “Is this something that will likely change in the future?”  If the answer is yes, consider putting it in a configuration file.  The more often you can change the behavior of your application without having to recompile it, the more often you’ll look like a hero.

Examples of good information to store in a configuration file:

  • Database connection strings
  • SMTP server information
  • Any standard to / from e-mail addresses
  • File upload / download / archive paths

#9 Scope and store your variables

Databases are awesome tools and nowadays pretty much any application you’ll be asked to develop will use one of some sort.  However, when thinking of application performance database access and transactions are very expensive operations.  With that in mind a good programmer will access the database as few times as possible in order to fill the needs of the current application request.

One way to facilitate this noble goal is to store any information that your application needs in memory once it has been retrieved from the database.  A “get once, use often” approach can go a long way towards helping with performance (and to a lesser degree code readability).  Some information that is used so often that is even worth storing as a session variable in order to eliminate a request (database, disk, whatever) altogether.  Be careful with those, though, as they are often targeted for hacks and should never be solely depended on for functionality and should never contain any private information.

#8 Never use arcane plugins

Plugins and third-party code can make development go much, much faster.  Often times you can get more complete functionality by using them but there are trade-offs for this convenience.

  1. You have to learn to think like the person who wrote the plugin in order to use it
  2. You usually don’t know how the internals work
  3. They’re almost never meant for the exact situation you’re in

With all that said, the right add-on or plugin can be a life saver and you must, must, must be careful when evaluating whether or not to use one.  Here are some questions to ask to help decide whether a plugin is right for your app:

  • Does it do everything I need exactly as I need it right out of the box?
  • Is it well documented?
  • Does it have an active user and support community?
  • Has it been updated to coincide with major platform releases?
  • Is the documentation in your native language (yes, seriously)?
  • Will it take longer to write the functionality myself than learn to work with this plugin?
  • When I (or someone else) inevitably has to maintain or change this app in the future will it be easy to work with or around this plugin?

If the answer to any of these questions is “no” you should be wary.

#7 Always remove unneeded functionality

This one kind of comes with a caveat:  every programmer should know to use a good and dependable source control tool.  Even if you are the only person working on the code, a good source control tool can (and likely will) prove to be a life saver at some point.  You’ll cruise along not even knowing you need it and then BAM – you implement sweeping code changes that break everything.  If you’re using a source control tool correctly, undoing your changes should be fairly quick and painless.  If not, you may have just lost a client or a job.

With that in mind, try to never, ever leave unneeded functionality in your code base.  If you have written a great piece of functionality that is no longer needed delete it immediately.

When you’re actually making changes that steer you away from existing functionality you understand why you no longer need the functionality and you likely have an idea of what else it touches.  When you come back in six months, after seeing two or three other projects, you will likely have NO idea why that functionality wasn’t previously removed.  You’ll think, “Boy, I didn’t remove this, something somewhere must be using it.”  This problem compounds itself when you’re forced to start writing code around undeleted, unnecessary functionality.  So in the end it’s easier to just remove code and keep your code base clean.

#6 Always consider performance

What makes a good programmer?  The ability to effectively juggle the following points and still deliver timely, effective solutions:

  • Performance – is the code minimal and fast?
  • Scalability – is the code able to be expanded upon easily?
  • Manageability – how quickly can modifications be evaluated, estimated and made?

The preference for which of these to focus on first differs from programmer to programmer and often from project to project.  This is part of what gives each programmer their individual style.  But good programmers always consider all three, no matter the situation.  Readability falls under manageability, abstraction falls under scalability and everything falls under performance.  So no matter what your programming personality and style is, you should be considering performance.

I’m not (necessarily) referring to spending hours pouring over 10 lines of code to make sure it executes as quickly as possible.  I’m talking about taking a solid fundamental approach to gathering and manipulating data that doesn’t do any one piece of functionality more times than absolutely necessary.  #9 above eludes to this, but to go a little further:

  • Get your data once and use it in as many places as possible before disposing of it.
  • Have the absolute minimum amount of functionality inside loops.
  • Never perform accesses (disk, database, service) from within a loop unless absolutely necessary.
  • (In strongly typed languages) Know and use appropriate data types.
  • (In web apps) Perform as few server requests as possible.

If you think of things like this from the beginning of your project you are less likely to have performance issues in the end.  If you don’t agree with me now that it’s worth the initial extra effort you will after you spend 4 weekends straight rewriting poor performing code because you tried to save 10 minutes on the front end.

#5 Never nest major logic / functionality in loops

I mentioned this one under heading #6 above, but it bears repeating.  Loops are often the heart of any application, but they will absolutely kill your app if used improperly.  So you must be wary of anything that falls into a loop.

Loops are something we have to use often, so every good programmer should know how to abstract functionality out of a loop (see #1 below for a simple example).  Besides the performance hits, tracing through functionality that is inside of a loop can be much more difficult because of all of the variables that come into play while looping.  Modern debuggers help tremendously with this task, but better tools shouldn’t excuse poor programming practices.

When you have time to review your code, start by reviewing loops and seeing if anything can be moved outside of them.

#4 Document effectively

There is a school of thought among some programmers that says, “Either you can read code or you can’t, why should I document it for you?”  And while this is true in theory, in practice adding appropriate documentation inside code makes it far, far easier to maintain.

Proper documentation is a skill and overdoing it is almost as big of an annoyance to those trying to maintain code as not doing it all.  Consider the following:

  • DO – denote reason and logic
  • DO NOT – denote functionality or process

What that means is:  tell the future programmer looking at this code why you did something, not necessarily how.  The “how” is the stuff they should usually be able to read on their own (unless you have to do some crazy, non-standard stuff).  More often when looking at the code they need to know “why” you did things a certain way.  Consider the following simple example:

for (int i = 0; i < var.length; i++) {

Now let’s consider two commenting options:

// iterate over each var
for (int i = 0; i < var.length; i++) { // increment i if it's less than vars.length
    doSomething(var[i]); // do something with the var at position i
} // finish the loop

- or -

for (int i = 0; i < var.length; i++) {
    doSomething(var[i]); // mark inactive vars for deletion

Now the first one tells you what is happening, about as pointlessly as a voice-over in a movie saying exactly what the characters on screen are doing. The second one assumes that you know what is happening functionally and instead just tells you what’s going on logically, which is far more valuable information when you’re in “put out the fire of the forest variety” mode.  In the first case, the future programmer would need to look up doSomething(var) and figure out what it was accomplishing. In the second version that information is at hand and valuable.

Which would you prefer if you got a call from an executive at 4:45PM on Friday that forced you to review this code?

#3 Use effective and logical variable names

There are a LOT of thoughts on this one and almost every programmer has a slightly different way of doing it.  So I’ll try to be ambiguous so we don’t start a war over it.

It is important to consider your variable names carefully.  Sometimes having the data type as part of the name is appropriate (intId) and sometimes that sort of thing can be inferred (id).  Either way, the name of the variable should hint towards the usage of the variable (note that “id” was in both).  Names like (vulSpok) and (humKirk) are not useful.

Now possibly just as important as choosing your style of naming variables carefully is being consistent.  As a programmer your code will have a certain “style” that others who inherit your code will have to learn in order to quickly and easily maintain your code.  That “style” may not be the same as theirs, but as long as it is consistent (and logical) you’ve done what you can do.

#2 Catch errors, or don’t

Let me start by saying that I know, academically, all errors should be caught and handled gracefully.  Let me also say that realistically, that almost never happens when deadlines are looming.

Hopefully the days of “Dr. Watson encountered an error” are behind us for good.  Most modern platforms will let applications die with a pretty decent error message.  So while it may not be ideal, letting errors fall through to the default error handling is better than manually mishandling the errors.  On internal or limited usage applications this can actually provide a pretty good idea of what the actual error is and where to start looking to fix it.

Now in an ideal world, programmers would have time to code a catch for anything that went wrong and do something cool, super-ninja style.  So if you have time and budget you should catch all possible errors and handle them.  If not, don’t catch them at all.

Just never, ever catch errors and do nothing.

#1 Never duplicate functionality

Reusable code is the holy grail of good programmers.  A good programmer should always be on the lookout for a way to write functionality once and then use it all over the place.  The benefits to this are too numerous to count.

So what is reusable code?

Let’s say, using our example above that you need to loop through your vars and doSomething() with them.  You could do it this way:

for (int i = 0; i < var.length; i++) {
    // mark inactive vars for deletion
    if (!var[i].isActive) {
        var[i].readyToDelete = true;
    } else {
        var[i].readyToDelete = false;

- or -

private void doSomething(var) {
    if (!var.isActive) {
        var.readyToDelete = true;
    } else {
        var.readyToDelete = false;
for (int i = 0; i < var.length; i++) {
    doSomething(var[i]); // mark inactive vars for deletion

It ends up being 3 extra lines of code in this example that will save you 4 lines of code each time you use it somewhere else.  So the first time you re-use the code in this rudimentary example you’ve saved yourself 75% effort across the board (coding, debugging, refactoring, etc).  Pretty nifty, huh?

Additionally, if you ever need to change the evaluation logic to, say, make sure that there weren’t any records that may be orphaned by deletion, you could change that logic in a single place and it would work everywhere throughout your code.

If you have any major items to add, feel free to do so in the comments.  If I get enough good ones perhaps I’ll update this article to include them.

Go to Top