Blindingly obvious rules for software teams

by Dan Cutting

Writing software is easy. Incredibly, astonishingly, easy.

And when you’re part of a team of other people with dumb opinions of their own, it’s even easier. Easy-peasy, if you will.

It’s so trivial, in fact, that it’s spawned a massive industry of books, training, and certifications explaining just how easy it is, if only you’d follow the right rules.

I figured it was high time I jumped on this bandwagon, so here are my rules for how to write software as a team.

These rules are “synthesised” (stolen) from many books, blogs, and movements (Beck, Cunningham, Feathers, Fowler, Martin, agile, craftsmanship, …), and from my own experience as a developer and team leader over the last decade or two.

No doubt my opinions will change over time, in which case I’ll deny all knowledge of this blog post.

1. Colocation

Sit together: front-/back-end developers, designers, testers, ops, support, and product owner.

Why? No “over the wall” mentality. Everybody focussed on what needs doing. But mainly it’s harder to be a jerk to somebody’s face. Unless you’re a sociopath. You’re not a sociopath, right?

2. Flow

Don’t sprint to arbitrary deadlines. Deliver a steady stream of small, completed features. Plan as you go. Use cycle time and its variability to estimate dates with degrees of confidence. Work hard to reduce variability.

Why? More sustainable pace. More predictable estimates. Fewer corners cut. No damn burndown charts or 3 day sprint planning meetings.

3. Physical board

Whiteboards, index cards, sharpies, sticky notes, avatars.

Why? Progress always visible to everybody. Highlights bottlenecks. Physical focal point for the team. Easy to collaboratively write & prioritise stories. Prompts interaction. Permanent markers smell really nice.

4. Correctness

No QA team safety net. Developers are responsible for proving their code works as expected using unit and acceptance tests.

Why? More ownership. Fewer bugs. Aids refactoring. Instant regression tests. No more having to explain yourself to people who only want to see you crash and burn.

5. Refactor, not rewrite

Learn how to improve legacy code, not just badmouth it. Always leave things slightly cleaner than when you found it.

Why? Start with all existing features from day 1. Rewrites take longer than you think. There is nothing in nature more despondent than the developer who has to maintain two diverging versions of the same product. They’re like a bedraggled kitten. Poor developer.

6. Pair programming

Different partners every day.

Why? Accountability. Just-in-time code review. Spreads knowledge of how code works. Encourages teamwork. Sparks creativity. Reduces number of bugs. Gives you valuable time to play with your phone when your partner is trying to figure out something annoyingly obvious. You could help them, but it’s a learning opportunity. It’s called mentoring.

7. Automation

Conspicuous continuous builds, unit tests, bug counts, and code quality reports.

Why? Emphasises quality. Frictionless releases. Pretty graphs that look very important and keep your boss off your back.

8. Deliberation

System architecture and UX must be deliberate, not a byproduct of coding. Know where you’re heading long-term as context for every story.

Why? Having a vision is key to a good, coherent product. If you just hack away from story to story without aiming for the stars, you’ll get stuck in a local maxima and end up making something like JIRA. The horror.

9. Shippable

Cover every edge case for the story you’re working on, even if it deviates from your deliberated design. That may mean doing “throwaway” work, even though you really, really know, for sure, 100%, that you’re going to be doing it differently in the next story.

Develop features in isolation, then merge to mainline when everybody’s happy with them.

Why? This is the heart of incremental flow. Half the time, the story you thought was next will be deprioritised. Everybody understands what they’ll get if they ship. No scrambling to back out unfinished work or add error handling before a release. There is no “done done”, only “done”.

There is no 10th rule

Shame really, or this post could have been called Cutting’s Coding Commandments.

So that’s how I see it. Easy, right?

What works for your team? @dcutting

Hi, I'm Dan Cutting. I mainly write Swift for iOS but love working on Mac apps, web APIs, and programming languages too.

Follow me on Twitter,, or GitHub or subscribe to the feed.