Home > Software Development > The Right Tool for the Job

The Right Tool for the Job

November 4th, 2009 Leave a comment Go to comments

“I need to nail this board down. Got a hammer?” asked Jim, the lowly construction worker.

John, the foreman replied, “We have a pneumatic nail driver we’ve been using. You’ll have to wait for that one.”

“But it’s just for a temporary brace while I put this wall up,” said Jim.

“We only do nailing with a pneumatic nail driver on this project.”

“It’s in too tight of a space to even fit the nair with this wall here. I can just reach a hammer in and nail it down,” said Jim.

John said definitively “No, we have to use the pneumatic nail driver. Everyone knows that hammers aren’t as good. You’ll need to cut a hole in that wall so it will fit in there.”

Any seasoned developer or any CS graduate can give you a laundry list of best practices when developing software. Things like “Don’t use globals,” “Have explicit garbage collection instead of depending on built in cleanup,” or “The use of GOTO will cause searing pain.” Good developers, however, will know that there are times when deviations to these rules is acceptable, and will at times produce software that doesn’t follow every best practice.

There are a couple of barriers to always following every best practice 100% of the time – developers who work for money are usually required to produce something functional on a fairly regular basis, and sometimes breaking a “best practice” provides a performance gain that cannot be easily translated following a “best practice.”

Now, this certainly isn’t to say that going cowboy/rogue and throwing out coding standards is ideal. Breaking these rules should by far be an exception, but there are times when it can be beneficial. If bending or breaking a rule gets you significant gain without impacting performance, security, maintainability, or portability of any likely foreseeable use of the code, I say go ahead and break it.

PHP has always been a “get it done” language.  Rasmus created the language as a tool to allow him to get things done faster.  The language certainly has changed since its original inception, but the “get it done” spirit of the language has always been fostered.  Sure, there are pieces of the language that don’t make a lot of sense, like  underscores or no underscores between words in standard functions, needle haystack precedence, etc.  Yet it is still arguably the most commonly used language to develop websites.  And that’s because with all of its quirks and peculiarities, it gets the job done.

Joel Spolsky refers to people who do this as “duct tape” programmers.  They may not have every aspect of the software done with every layer of abstraction that your CS book says you need.  But they deliver software that is maintainable, done close to on schedule, and most importantly, works.

So follow the best practices wherever you can.  But when it makes sense to deviate from your CS Best Practices book, remember you’re coding to deliver a working product, not to get a grade on your source code.

Categories: Software Development
  1. No comments yet.
  1. No trackbacks yet.