I love stoplights

I love stoplights.

No, seriously. I think stoplights are amazing.

No, I’m not just looking at things in the world and saying that I love them.

No, I don't like stopping at them any more than the next guy, and I may or may not speed up to make it through yellow lights (I do), but that doesn't mean that I don't love them.

I love stoplights because they work. I know that sounds, for lack of a better word, silly, but it's true. I love stoplights because when they tell me to stop, there's a good reason, and when they tell me to go, it's reasonable to assume that it’s safe to do so. They are simple and clear and solve a major issue in an elegant way.

I have seen shows on television where stoplights in two different directions turn green at the same time. Chaos inevitably ensues as people from two directions crash into each other.  In real life, I have never seen this happen. Have you? Now, I'm sure there are a few occasions where it actually has occurred, but considering the staggering number of stoplights the world over, and the volume of vehicles on the roads, it is amazing to me that I've never even heard of a malfunction of this nature.

Why is it that I've never heard of a stoplight malfunction?  Well, first off, I'm sure the actual "programming" behind a stoplight isn't outrageously complex (I’m not saying there aren’t complexities, but the number of variables in play is relatively low compared to, say, the engineering of a space shuttle). Second, the stoplight had the opportunity to be developed and tested over a long period of time; it wasn't installed and then immediately used by a million people. Lastly, I believe that - probably due to the safety factors at play - people spent a lot of energy on making sure they built a quality solution.

So, this brings me back to why I love stoplights: they work as they're expected to, usually without fail.  As a Drupal development shop, rarely does what we do have life, death, or a 5-car pileup in the balance, but I don't think it means we should take any less pride or focus any less on crafting a quality solution than the makers of the stoplight. We're building websites, and at the end of the day, I want every client to feel and know that we consider their problems important and that our solutions need to weather the test of time and avoid "crashes."

Based on my affinity for stoplights, I’ve got three lessons that I think are relevant to development in Drupal at Achieve:
 

1. Keep it simple. Simple solutions are easier to maintain and easier to ensure correct behavior. There are often hundreds of solutions to a problem. When it's all said and done, simpler will consistently be preferable to complex. A thousand lights on a stoplight may have made it more informative, but it would have made it less usable. In Drupal, this might mean using a well-developed contributed module rather than crafting a completely custom solution or not building five modules to solve a simple problem.
2. Test and test again. Write unit tests to ensure that the ins-and-outs of what you develop actually behave as you expect, and ensure that everything that goes out the door is working as you expect it to be. Check your code, have someone else check your code, make sure it works. You wouldn't install a stoplight, cross your fingers, and hope it worked; likewise, you shouldn't write code, put it on a site and hope that everything functions as expected. You should know - as much as is knowable - that your code is going to do what you want it to.  In Drupal, this means that writing simpletests is a good thing and having someone else test your work before the client sees it is an absolute must.
3. Focus on quality. At Achieve Internet our goal is to write solutions that solve the problem once and for all. Items 1 and 2 above make this far easier to be certain, but if you focus on creating a quality solution, you're far less likely to settle for something that merely gets the job done. A stoplight that failed 5% or 10% or even 1% of the time would be a terrible stoplight, and code that fails at that rate should also be considered a failure. Similarly, because the stoplight is a quality product that has stood the test of time, so should your code. In Drupal, this means that given an option between "just getting it done" and "doing it right," you should always err on the side of "doing it right." A poorly crafted solution, hastily developed or under-developed, will always end in failure.

There's always going to be a tradeoff in programming between time and how much can be accomplished. Drupal is no different. I'm not advocating over-engineering solutions or testing for six months before release, but I am saying that every solution - even simple ones - can be crafted with quality and with an eye on being reusable and robust. We may not be building stoplights, we're definitely not going to always be perfect, and the world won't end tomorrow based on anything we do or don't do. That being said, here's hoping that the web works a little better and that "traffic" flows a little easier because every day we're focused on building solutions as enduring - and of as high quality - as the stoplight.