Is your consulting code an asset or a liability?

NOTE: I originally posted this at my old company's website in 2010,
but as that blog has been taken down, I thought I'd resurrect this
post here.


When you hire consultants to build software for you, how do you know if the code is worth the money you pay them?

Consulting code (indeed, any custom code) should be an asset to your business, but unfortunately, many times it’s quite the opposite.

Consulting code can become a liability. Lack of tests and poor quality, buggy code can leave you, your code and your pocket book in worse shape than before the consultants arrived (and usually with little to no recourse).

Untested code has no business value

Years ago at the Agile 2006 conference, one of the sessions was “Delivering flawless tested software every iteration”, delivered by Alex Pukinskis. The catchy name attracted a big audience and it was standing room only.

During this presentation, Alex made the following statement: ((I’m not sure whether Alex was quoting someone, but googling that precise phrase returned zero results, so I’m attributing it to him))

Untested code has no business value

This struck a chord with me, because at the time I was working for a company that was trying to transition to agile, but many of our practices still hadn’t changed. We were (okay I was) still breaking the build and still expecting the QA team to find our bugs for us. We weren’t consistently doing TDD, we had no automation of the build acceptance and we were not practicing continuous integration. I could go on, but I’m sure you get the idea.

The “aha” moment for me was the concept that the quality of the code, and a lack of defects was my responsibility as a professional developer. It was my responsibility to ensure that no defects were passed to QA. Of course, I know that software cannot be perfect, and there will be defects, but my attitude towards defects changed after that talk. Defects should be unexpected. Defects should be unusual. Defects should be prevented, not found.

No Bugs

The attitude that defects should be prevented, not found, can be summarized in the “No Bugs” philosophy.

James Shore recently published the full text of the No Bugs section from his excellent Art of Agile book. He summarizes the text in 99 words:

Rather than fixing bugs, agile methods strive to prevent them.

Test-driven development structures work into easily-verifiable steps. Pair programming provides instant peer review, enhances brainpower, and maintains self-discipline. Energized work reduces silly mistakes. Coding standards and a “done done” checklist catch common errors.

On-site customers clarify requirements and discover misunderstandings. Customer tests communicate complicated domain rules. Iteration demos allow stakeholders to correct the team’s course.

Simple design, refactoring, slack, collective code ownership, and fixing bugs early eliminates bug breeding grounds. Exploratory testing discovers teams’ blind spots, and root-cause analysis allows teams to eliminate them.

Asking the right questions

Now you are probably expecting some sales pitch from me at this point to say that you should hire us because we’re great. Well that’s not the point of this post (although you should, and we are). The point of this post is that the next time you are talking to a consulting firm or hiring a developer (( For more information on hiring developer team members, read, ask them about their definition of code quality and how they ensure it. By simply asking a couple of questions you should be able to determine whether they are all “smoke and mirrors” or if they will add value to your business. For example, you might ask:

  1. What is your definition of quality code?
  2. How do you ensure your code is bug free?

The answer to the first question should mention practices like the Law of Demeter, coding standards, refactoring and adherence to the SOLID principles.

Although unsettling, it is okay if the answer to the second question is “I‘m never 100% sure my code is bug free” (particularly if they mention Gödel’s proofs). However, they should quickly follow up with, “I make bugs less likely by practicing test driven development, peer reviews (or pair programming), automated acceptance tests and adherence to coding standards and good design principles.”

If they can answer those two questions to your satisfaction (and follow through by demonstrating these practices when building the code) then they might know what they are talking about, and actually give you value for your money.