Quality Coding Manifesto

What is agile software development at your company? Was it mandated from the top? Did the company bring in an external consultant to train everyone? Are you now working in 2-week sprints, so the pressure is constant and you always have crunch time? 

I’m Jon Reid with QualityCoding.org, where we train iOS teams in technical agile practices. Specifically, we focus on: 

• unit testing 
• test-driven development 
• refactoring

Why those three things, and what does this have to do with agile?

What Scrum Doesn’t Do

Let’s imagine we’re not doing software development. Instead, we’re trying to run a hospital. Our hospital isn’t meeting its goals for patient recovery. So we change how we run meetings, how we set targets, and how often we get feedback. Everyone is very busy… but patient recovery doesn’t improve. Not until someone points out that we’re following unsanitary practices. If we’re not washing hands or sterilizing instruments, it doesn’t matter how we do project management.

No hospital would switch their management style while ignoring medicine and science. But this is what we do in software. The most common agile method is Scrum. But search the Scrum Guide for anything about software practices. Go ahead, do a search. You won’t find anything.

Now this is not a slam against Scrum. Scrum was born out of software development, but they deliberately left that part out. They wanted to provide a framework that works in a variety of contexts. Rather than ignoring software practices, Scrum assumes you already have them.

The problem is, Scrum doesn’t explicitly call out this assumption. So company after company adopts Scrum assuming this will make them “agile.” Business likes it because they get to crack their whips every other week. And many developers hate it, because there are more meetings and constant pressure.

But think back to our imaginary hospital. The problem wasn’t that they changed their project management. The problem was that they were following unsanitary practices. Better project management just makes underlying problems easier to see.

Extreme Programming

There are a few key ingredients to success with agility. You need to slice stories into incremental deliveries. You need to change who works together, and how they collaborate. But for software, you also need to change how you write and deliver your code.

These days, the software practices you need are called “technical agile practices.” But in the early days, they went by a different name: Extreme Programming. Kent Beck’s idea behind Extreme Programming was simple and subversive. He asked, if some practice yielded good results, what happens if we dial that practice all the way up? What if we take it to an extreme level?

So take something like code reviews. Nowadays that happens in pull requests. What is a code review taken to an extreme? It’s pair programming. And lately, folks have taken pair programming itself to a new extreme of mob programming.

Or take unit testing. What does it look like to take unit tests to an extreme? Well, what if you write the test first? This idea grew into test-driven development.

The one Extreme Programming practice that took off is continuous integration, or CI. Even with this widespread success, it’s still misunderstood. We can see this because teams often assume that just because they use a CI server, this means they’re practicing CI…?

Bringing Extreme Back

Extreme Programming was one of the foundations for what became known as “agile.” But except for continuous integration, the software practices were generally left behind. Companies hired non-developers to teach agility to their development teams.

So let’s bring these practices back. The practice I see as the cornerstone of software agility is refactoring. Think back to the Manifesto for Agile Software Development. One of the four statements is that

We value responding to change over following a plan.

Refactoring is changing the design of existing code without changing its functionality. We continually need new designs to support changes to our code. Refactoring is preparing your code for those changes.

But across our industry, the meaning of refactoring has been diluted and changed. People say they’re refactoring, but most of the time they mean they’re rewriting some code, and changing the feature set. Let’s get back to the original definition. Disciplined refactoring is moving things around without changing the functionality. It’s a series of small steps, using tests to verify each step.

This means unit tests become a precondition for effective refactoring. Then unit tests and refactoring join to form test-driven development, or TDD. TDD may be “test-driven,” but what is the center, and what is it driving toward? The center is adding new functionality. The goal is to lay a foundation for continuous refactoring.

The technical agile practices aren’t language or platform specific. You should learn them from a variety of teachers. But the practices that come down to actual code can be hard to grasp until you see them in your own programming language on the platform you use. So Quality Coding is for iOS developers. My content and training focuses on unit testing, test-driven development, and refactoring—particularly in the context of Apple languages and platforms.

I’m not claiming that agility is only the software. GeePaw Hill talks about:

• the Made
• the Making
• the Makers

The Makers is us, learning to be kind and inclusive, working together rather than in solo caves. The Making includes finding ways to deliver value sooner to get feedback sooner. But the Made is part of it, too. And that’s not only the user experience. It’s the code itself, and here’s why…

The Manifesto

This is the Quality Coding Manifesto: The code itself determines how agile you can be. Your code can accommodate change, or it can resist change. To succeed with agility, you need to drive down the cost of change. And the best way I know to do that is with:

• unit testing
• test-driven development
• refactoring

Quality Coding is here to equip your iOS team in these and other technical agile practices. Because you can only be as agile as your code lets you be.