Why your developer's coding style matters to you

Submitted by Brandon Cone on 07/17/2013 - 10:05:am

When you're hiring a Drupal developer it's easy (and useful) to spend time considering the developer's (or their company's) proposal and price.  What often times gets overlooked is the development company's commitment to maintainable source code.  Equally important with a robust architecture and agreeable price point is knowing that the developers you hire are writing good code.  Here's a quick list of what matters to developers and should matter to you: 

  1. It shows that they are professionals and care about their work and what they do.
    1. You wouldn't use a mechanic who throws his tools around the shop or a carpenter who can't find his hammer because the way they do their job is as important as the job they do.  You want to hire someone who you know cares about the job they do and takes time to make sure it's done right.
  2. Well documented code is easier to maintain.
    1. Well documented code usually means well architected code.  At the very least a developer won't have to spend time up front debugging to understand what is happening.  
    2. Well architected code (implied by well documented) is more stable.  If a developer has taken time to make sure it's a safe bet that the code's Coupling score will be low and Cohesion score will be high (these two metrics have an inverse relationship).  Think of coupling as the ripple effect of changing a piece of code.  Highly coupled code will have large and cascading ripple effects throughout the Drupal system (across layers). Highly coupled code is very fragile.  Highly cohesive code, on the other hand, means it can largely stand on its own and stays within its respective boundaries.  Highly cohesive code is very stable.  
  3. Developers charge more to inherit poorly written code.
    1. Poorly written code is high risk to a developer.  It's hard to understand, generally doesn't follow standard conventions, and gives no guarantee that custom code is limited to custom modules.  Often times if a developer doesn't care to follow standards, they have no reservations about "hacking" Drupal core and contributed modules.  
    2. Inheriting bad code means a steep learning curve to understand what the previous developer was doing.  As such, a company will charge for this time plus build in risk time due to the uncertainty of stepping into the project. 
  4. It's less expensive in the long term.
    1. Coming back into poorly-written code after not working on it for a while requires the developer to take time to re-learn what is happening - even the one who wrote it.
    2. This gets compounded if there is a development team as each time a different developer works on your code they have to spend extra time on "knowledge transfer" to learn what another member of the team was trying to accomplish with a given piece of code.

So what can you do to ensure that you're hiring a company that writes good code?  Unless your prospective a company is going to let you review some of their code, making sure you hire a good company can be difficult.  Here are a few things to pay attention to as you look for a site developer.

  • Pay attention to the professionalism (or lack of) with which they conduct themselves in meetings.
  • Ask questions about their process.  A company with structured processes increases your confidence level that they are doing things right. 
  • Ask questions about their code review cycles.  The more eyes on the code (especially custom code) the more certainty you can have that it is actually good code.

The moral of the story is that you sometimes have to be willing to pay more up front to get a better, less expensive product in the long run.  Up front savings can turn into really expensive, drawn-out processes down the road.