What is good code?

We often discuss the principles we use to write what we consider good code - test-driven development, object-oriented programming, SOLID, DRY, 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.

SOLID principles create individual components that help us understand code. SOLID 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, DRY, or SOLID. 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.

Doing Stupid Things Is A Choice

This is the first post in what will be possibly be a 25-part series of business mantras. Each day I will select (or possibly create on the spot) a barely-thought-out phrase, motto, slogan or saying – back it up with a flimsy circumstantial account – and steadfastly insist that it’s correct, possibly in the face of evidence to the contrary.

The mantra of today, day one in this twenty five part series, is “Doing Stupid Things Is A Choice”.

If you work in a large organization, or for the government, or for a smaller organization with an inexplicable bureaucracy problem—you probably know a person or a whole team of people within your organization who have a consistently defeatist attitude about things. They assume deadlines will slip. They assume that work of a subpar quality will be delivered internally. They assume that the messy, complicated and useless processes that exist are “just the way things are” and they don’t care enough to change them.

Similarly, maybe you’ve known that there was a “right way” to do something, but felt that because of organizational politics or incompetence, you needed to find a round-about way of getting there—usually by doing 10 things wrong first.

These systems don’t come into existence by themselves, and they don’t perpetuate themselves either. Each of these attitudes and views about the way things and the way things must be is the result of constant decision making that could be stopped at any moment at all by anyone involved.

No matter what you’re doing or why you’re doing it—you only get one life. In my life, accepting failure and incompetence just because “that’s the way things work here” simply isn’t good enough.

So stop making excuses next time you feel resigned to failure because of some entrenched practice in your organization. By perpetuating the attitude of disappointment, you’re part of the problem.