4 Rules Of Simple Design

There is a lot of talk out there about everyone wanting the “best” developer, but there isn’t really a great definition of what a good developer is. It’s pretty “easy” to make something work, so it’s really hard to tell a good developer from a bad one just based on that criteria.

Luckily, today I got to participate in a Code Retreat workshop led by Corey Haines, who gave a great definition of what a better software design is. A better design makes it easier to make changes.


As software developers, we’re going to constantly change our code, whether it’s to add a new feature or because the client doesn’t like how the first version works. So good code is one that is really really easy to change.

Having that framework in mind, Corey Haines listed out 4 rules for simple software design:

Passing Tests

The faster you can find what’s broken, the faster you can change it. Test driven development (TDD) tells you exactly what method broke when you removed or added a new piece of code. Without tests, your code design isn’t good.

Reveals Intent

Good design makes it really easy to understand the code’s intent. Having really good names for your methods is essential for this rule. The faster you can figure out what the intent of the broken code was, the faster you can fix it when making changes.

No Duplication (DRY)

How many places in your code do you need to change if only one requirement changes? You want to minimize that number to only one place.

Keep It Small

It’s OK to delete code you don’t need anymore. Sure, you spent a whole day on it, but it’s OK. Just delete it. Don’t comment it out and leave it there. Just DELETE IT. This keeps your code clean for when you’re going through it to make changes.

Enjoy the article? Join over 17,500+ Swift developers and enthusiasts who get my weekly updates.