---
title: What is good code?
teaser: What are the fundamentals of good code?
tags: playbook,good code
author: Joe Ferris
published_on: 2012-04-25
---

We often discuss the principles we use to write what we consider good code -
test-driven development, object-oriented programming, <abbr title="Single
responsibility, Open-closed, Liskov substitution, Interface segregation and
Dependency inversion">SOLID</abbr>, <abbr title="Don't Repeat
Yourself">DRY</abbr>, Law of Demeter - the list goes on. Sometimes it's useful
to remind ourselves of the fundamentals.

## What is the code for

Code makes an application work for users. Getting tests passing or removing
duplication is useful, but the code needs to __be shipped__ so that __users can
use it__.

## What kind of code is good

Code needs to __work__. Assuming that as a prerequisite...

When code is __easy to understand__, we can change or extend it faster and are
less likely to make a mistake in the process. Readability counts.

When code is __easy to change__, we can iterate on user feedback faster.

When code is __fun to work with__, we're happier. Building software is our full
time job. If we go home every day feeling wrung dry, something is wrong with our
process.

## Does good code matter

Yes. Following certain principles can result in shipping products __faster__
with __fewer bugs__ and more __programmer happiness__.

## How do our principles result in good code

Test-driven development helps us understand code because we state the reason for
each line of application code in the test. It also makes us happy by providing a
clear process for working.

An automated test suite helps us change code because we have an early warning
system when we break an existing component. It is fun to work with because we're
more confident and less fearful.

Removing duplication helps us read code by introducing semantic concepts and
abstracting details. It also helps us change code by reducing the amount of code
that needs to be touched for each change.

<abbr title="Single responsibility, Open-closed, Liskov substitution, Interface
segregation and Dependency inversion">SOLID</abbr> principles create individual
components that help us understand code. <abbr title="Single responsibility,
Open-closed, Liskov substitution, Interface segregation and Dependency
inversion">SOLID</abbr> helps us change code because components are reusable,
swappable, and small.

## How do our principles result in bad code

Slow or brittle tests make code harder to change. We have to be careful about
writing the correct tests and the correct amount of tests.

## Are we writing good code right now

Code isn't good when it's tested, <abbr title="Don't Repeat
Yourself">DRY</abbr>, or <abbr title="Single responsibility, Open-closed, Liskov
substitution, Interface segregation and Dependency inversion">SOLID</abbr>. Code
is good when it works and we can work with it. When our teammates can understand
our code quickly, respond to change, and are relaxed and happy, we're writing
good code.