Make it Work. Make it Right. Make it Fast.

Published 2012-12-15

I strive to follow a simple, disciplined and pragmatic approach to software engineering, which I've borrowed from Kent Beck and learned through blood and sweat: Make it work. Make it right. Make it fast.

People commonly mistake this for the adage "Good, cheap, or fast. Pick any two.", which represents the three axes of control that a product owner has to tweak delivery timelines. These two ideas are only vaguely related (in the sense that if you don't Make it Right, Work, and Fast, you'll choose none from the preceeding selection). But the relation stops there.

Make it Work > Right > Fast is not a choice. It's the order in which you do things.

What is "it"?

The first step in making "it" work is actually defining what "it" is. Joel Spolsky calls this a "spec". Agile people call to this "user stories". Normal people call this "planning". Whatever your religious preference, the first step in doing anything is figuring out what you're going to do.

This is very important for two reasons:

  1. Knowing actual use-cases makes it possible to make design decisions and tradeoffs regarding architecture and features.
  2. Clearly defined objectives provide a shield against scope creep.

The simpler and better-defined your scope of work, the easier it will be to build a high quality product. It will also be less risky.

Make it Work

Once you know what you're going to build, build it! Do the simplest thing that could possibly work. Commit any sin necessary to get it working. Don't stop until it works.

But don't forget, it's not done until you've Made it Right and Fast.

Make it Right

Ideation and creation is mostly a process of trying, failing, and utlimately correcting your design. Good design is easy to change when you get it wrong, and easy to extend when you get it right.

If you don't hit the sweet spot the first time, slow down and correct so you can stay on target without increasing effort as your project grows. If you've made a mess, take some time to go back and clean it up before you start working again. Factor out duplication. Expand your tests.

Make it Fast

Make it fast has two meanings to me. The first is to spend some time optimizing your code, adding caching, etc. Fast applications deliver business value more quickly, they're easier and more enjoyable to work with, and less costly to deploy and maintain.

The second aspect to speed is streamlining your development process. Maintenance is the most expensive phase of software development. Automate your tests and builds. Factor common code into libraries so they can be more easily maintained and reused. Write documentation. Eliminate manual effort in your process so you can accomplish the same work faster.

Make it Repeatable

As a final thought, I've tacked on my own step. Make your process repeatable. A disciplined team overcomes new obstacles and builds success by creating a predictable environment and controlling the amount of uncertainty in a project. When you fail, learn from your mistakes -- don't hide from them. Establish patterns and reuse proven techniques. Build and maintain the teams and practices you need to win consistently.