Analysis Paralysis and the Editor

"If you ever talk to a great programmer, you'll find he knows his tools like an artist knows his paintbrushes."

Bill Gates

 

Whatever your opinion of Microsoft, there's no denying that Bill Gates is, or was, a talented developer. When he made the above comment in a 1986 interview he may have been referring to more primitive versions of our modern programming tools, but it remains true today; a developer not utilising the best tools for their task, or who does not take time to learn to use those tools properly, is not likely to be a great developer. That interview is worth a read, by the way - I came across it through Coding Horror.

Many reasons could explain why otherwise competent programmers often underestimate the impact good tools can have on the development of great software, but sadly the most obvious is probably ignorance. When I started my career, I was the sole developer in my company. The editor I came to use, Macromedia (now Adobe) Dreamweaver, had been purchased prior to my arrival. Not knowing any better I ran with it, never stopping to think that it may not have been the most effective tool for my task. It allowed me to do what I wanted to do, and nobody was recommending anything different, so I never thought to look elsewhere for other, better options. Sometimes we simply aren't aware of the range of products that are available to us, often free of charge. 

Another explanation could be that we become so embroiled in our primary task - writing code - that in focusing on meeting 'The Deadline' finding time to investigate tools just isn't a priority. Again I experienced this firsthand - immediately after joining Box UK I was so preoccupied with getting up to speed with Amaxus, our Web Content Management System, and attempting to write top-notch code that it took me a few months to realise the IDE I was using, UltraEdit, wasn't much better than the one I'd left behind. This eventual epiphany led me to seriously consider for the first time what options I had, and therefore which tools I should be using if I was going to be as productive and efficient as possible. So while I'm not what Bill Gates would consider a great programmer, I have come to appreciate the importance of the right tools, used correctly.

So far, I've only cited editors when referring to tools. This is because they are responsible for the most critical part of a developer's workflow - that concerning the writing of code - and so are a good reference point. This is not to suggest that it is only editors to which Bill's statement applies. In order to keep this article concise I'll focus on editors, but we could substitute 'editor' for 'virtual machine', 'database administration utility', 'build system' or 'test suite' and draw the same conclusions.

Finding a good editor can be hard, but sometimes making the effort to find one can be harder. If I think back to my first job, I remember that while I was aware that there were other editors on the market, I had no idea what made one of many better than the rest. It was easier for me to stick with a product that definitely 'worked' than to potentially waste time trying to find another that might offer more. The sheer volume of options made it feel safer for me to stay in my comfort zone.

It turns out that there's a theory that explains this far better than I could - Schwartz' Paradox of Choice. This argues that an abundance of choice for the consumer can cause 'analysis paralysis' - where the consumer is unable to make a decision, or is forced into making a rushed, inconsiderate selection. Thankfully Schwartz also detailed 6 steps that chart a path through indecision, which I'll paraphrase for our situation.

Figure out your goal or goals

Well, surely we only have one - we want to write code! But we actually have a few more. Since we're ultra-professional we want to write it quickly and correctly. If we're disciples of the Joel Test then we'll want to make sure the code's persisted to some sort of version control. We'll have other requirements that depend on the languages we use too, like syntax highlighting or build compilation. So we can't underestimate our requirements, and ideally we'll find a solution that supports them all.

Evaluate the importance of each goal

That will depend on personal opinion, but I think it's valid to say that the general goals listed above are necessary for any decent software project and are thus equally important, while context-specific goals will have a varying degree of importance and may be more likely to represent 'nice-to-haves'.

Examine the options

This is the time consuming part - we need to make as exhaustive a list as possible of potential candidates. We could do this by running though a list of products, asking colleagues or the online community for recommendations, or through searching, using terms that relate to our goals. The most important thing at this stage is to not allow bias to impugn on our selection. The Availability Heuristic warns against the use of anecdotal evidence in a decision making process, so it's important to be as open-minded as possible at this stage. Don't rule out products based on previous encounters, as newer versions may be more capable.

Evaluate how likely each of the options is to achieve your goals

Now run though each of our candidates, looking for one (or more) with features that meet the requirements. The promising ones should be evaluated. If they're not free (as in beer) look for a trial version, although in these cases some features will be disabled, making the product more difficult to evaluate. Nevertheless, unless we've got some pretty stringent requirements we should find ourselves with a couple of encouraging options. These will be stable, well supported products that meet many, if not all, of our goals.

Pick the winning option

It's important that once we think we've found a winner, we don't hesitate; it's time to start using it. If we identified a few just pick one - if it doesn't work out, we can always drop it for another.

Modify goals

Once we've started using a product, we may find that it's not meeting our criteria after all, or we may develop additional requirements that the product doesn't cater for. Schwartz says we must use the consequences of our choice to modify our goals, so we must always question whether the product is delivering. This is particularly relevant once some time has passed, as our tasks change or technology evolves. 

For example, I didn't realise how important an editor with an efficient, quick search was until I was involved in some heavy refactoring of a project involving hundreds of classes. Navigating a codebase of that size is frustrating when finding and opening files takes an inordinate amount of time. Moving to a product (Netbeans) with excellent codebase navigation brought an immediate improvement - until I discovered that program instability meant that I was sometimes lucky to get a file open at all! Thankfully recent versions have suffered less from that handicap, but these examples serve to illuminate the fact that it's unlikely we'll ever be fully happy with a choice, and must always look to improve it while never letting familiarity or lethargy prevent us from using the best tool possible.

To summarise: don't settle. If you've been using the same product a substantial amount of time (I'd say a year), look around for alternatives since even if it was the best choice then, it's not necessarily the best choice now. If you've only ever used one product, it's critical you get some perspective by trying others as you could dramatically improve your workflow. Not just in terms of efficiency, but usablilty; it's so much nicer using a product that doesn't feel like its fighting you at every turn. Even if you're happy with your current solution and there's nothing that is obviously better, get in touch with the community of developers and work to make it a better product by reporting bugs, developing add-ons and requesting features.

Finally, finding the right editor is one thing; using it properly is another. In a follow-up I'll take a look at some techniques and features all developers should be familiar with to make the best use of their editor of choice.