It’s not about the unit tests


iOS developers generally don’t unit test. So why then do they as a community seem to enjoy a reputation of quality.

No unit tests. No continuous integration. No TDD.

That pretty much summarizes my last project. It was my first paying iOS gig, and not only did we not apply these cherished practices, we shipped a high quality product.

This really bugged me.

I had always thought unit tests were essential. But this experience with iOS seemed to challenge some deeply cherished assumptions I had developed over the years about writing software, and led me to ask myself some very uncomfortable questions.

Was I regressing in my development practices?
Were unit tests not essential?
Was there something different about iOS development?
And how did the iOS community ship quality product, without unit tests at their core?

These questions kept me up and night, and led to the soul searching contained within this article.

Challenged assumptions

Ten years ago I used to debate people on the merits of unit testing. Not any more. Unit testing has become such a common practice that you’d struggle to find a modern development platform that doesn’t have some sort of automated testing framework.

And why not? The benefits are obvious. You can release, change, and refactor your code with confidence. You save a ton on regression testing. And the feeling of security that comes from knowing you have a suite automated unit tests backing your every change is undeniable.

So imagine my surprise when I entered a community responsible for some of the worlds most loved mobile applications, only to discover they don’t unit test. Even more disturbing, they seem to be getting away with it!

What’s different about iOS?

While I won’t say developing apps on iOS is easier, there are a few things iOS developers have going for them.

1. Smaller screen size.

You can’t fit a lot on a mobile phone screen — there just isn’t a lot of room. The apps also tend to be smaller (many don’t even have a backend). This, when combined with a culture of minimalism, dramatically simplifies things in terms of code and data. There is simply less of both.

2. No legacy.

Mobile apps are so new, iOS developers typically aren’t burdened with 100,000 lines of legacy code the way enterprise developers sometimes are. This let’s them start from scratch unencumbered.

3. One language.

You can build an iOS application knowing only one language: Objective-C. The typical web developer needs no fewer than four or five languages to do anything other than static HTML.

4. A mature platform.

A lot of the heavy lifting is done for you in iOS. If you need to do something with photos, music, or Facebook it’s there. You just plugin.

5. Very visual.

This was probably the biggest difference for me coming from the enterprise. Instead of spending days wading through layers of architecture (mocking and unit testing every step of the way), iOS developer have almost no layers of architecture. They spend almost all their time at the UI layer.

That means the nature of the code they write is often visual. The only way to see if it works is to fire up the simulator and try it out.

As interesting as these differences are however, they still don’t tell the whole story. If they did, every mobile platform would enjoy this higher level of quality. Nope there’s something else going on. Something bigger.

Who cares?

When you do something for a long time, it’s easy to forget what people in your field once did without.

  • Architects used to work with slide rules.
  • Seafarers used to navigate by the stars.
  • Artists used to work solely with their bare hands.
  • Programmers used to program without unit tests (often at a much higher quality they you see today).

And yet in all these fields, practitioners were able to achieve what we today, with all our modern tools, would admit was a high level of quality in their work. What was their secret?

They cared.

These people simply cared more about their craft, and what they were doing, than their contemporaries. They ‘out cared’ the competition. And that is what I see in the iOS community.

They care more about the art.
They care a lot about the exact wording and spacing of text on buttons.
They care a lot of the speed and performance.
And they care a ton about affordances (like remembering where in the scroll list a user was when they put the application in the background).

Apple works very hard to make sure every developer in their ecosystem cares, and they give them the tools so they have no excuse not to.

They walk them painstakingly through how to creating beautiful art for their apps.
They share (and enforce) human interface guidelines for mobile application development.
They curate and block apps that don’t meet certain quality or standards.
And their former CEO was known for calling people up in the middle of the night and tweaking the color of a logo.

It’s in the communities DNA. Here is the letter you get on your first day starting at Apple.

These guys care. They care like artists care. And—I’m just citing my own experience here— the same can’t be said for other platforms I have been a part of.

What does this have to do with unit tests?

Absolutely nothing. And that’s my point.

What leads to quality is something much bigger—more than a collection of software engineering techniques or a collection of practices.

When I entered this community I was under the false impression that if you didn’t write software the way I did, you must be doing it wrong.

Instead I discovered a community that cared more about quality than I did, and that I still had a lot to learn about crafting a quality experience.

That’s what this whole things has taught me. It’s not about the practices. It’s about the spirit, intent, and in which they are applied. Used when applicable. Quickly abandoned when not.

Are unit tests an invaluable tool for writing great software? Heck yes.
Am I going to produce a poor product if I can’t unit test? Hell no.

And that is what this experience taught me. I need to be more than a collection of practices. I will unit test where I can (including iOS) and I will doing whatever else it takes where I can’t.

All I can say is to keep growing sometimes we need to challenge our most cherished assumptions. It doesn’t always feel good, but that’s how we grow, gain experience, and turn knowledge into wisdom.

The second you think you’ve got it all figured out you’ve stopped living.

If you want to see how far down the rabbit hole this whole discussion on quality can go, I suggest picking up a copy of Zen and the Art of Motorcycle Maintenance. It’s not an easy read. But it may change your life.

Oh ya, and keep unit testing.


Portuguese translation courtesy of Sylvestre Mergulhão.


Production Readiness


Something that doesn’t get talked about enough in agile development is production readiness—the practice of continuously having your code in a state where it could be deployed at a moment’s notice.

Everybody gets the importance of co-location. Most people understand the speed and efficiency that come from user stories. But rarely do I hear people talk about the importance (and challenge) of continuous production readiness.

In this article I want to get into what agile production readiness is, why it’s so important for you and your project, and what you can do to get there.

What is production readiness?

Production readiness is the practice of ensuring that your software is continuously in a state where it could be shipped at a moment’s notice.

It’s an attitude and a mindset in which the team treats the first iteration of their software as something that could potentially be shipped, and each iteration thereafter as simply updates to a live production system.

Yes. When we are not in production, there are a lot of things we don’t have to worry about.

  • We don’t have to worry about testing (can do that later).
  • We don’t have to fix bugs (can always do that before we go live).
  • We don’t have to demo our software (it’s still in development, after all).
  • And we don’t have to integrate everything together (it’s easier just to hook it all up in the end).

You can see where I am going with this.

These are exactly the kind of things that, as agile practitioners, we want to be doing early and often in our software. We can reduce a lot of risk by acting as if we had to release it every week. That doesn’t mean we do (there are probably a lot of really important features like security and validation that won’t be done in iteration one). But our attitude is we could if we had to.

What Does This Buy You?

There are a lot of benefits that come from treating your software with this kind of respect from day one.

You go faster

Maybe not initially, but once you get into the rhythm of regularly producing working software you spend less time:

  • fixing bugs
  • deploying emergency patches
  • re-writing broken features
  • explaining why your project is late and nothing works

And more time:

  • improving your customer experience
  • adding (or removing) new features
  • and wowing your customer in unexpected ways

These benefits don’t come free. You have to write tests, get feedback, and tackle tough problems early. But once you make these investments, you reap great dividends later on in terms of time and money.

It makes planning simpler

No need for shenanigans or tomfoolery with the schedule and plan. Features are either done or they are not. It removes any doubt with regard to where you are with the project, and how much you have left to do.

It reinforces the good

To regularly produce shippable code each week there are certain things you’ve got to be doing:

  • You’ve got to break big problems down into smaller, more manageable ones.
  • You’ve got to test from the start.
  • You’ve got to improve and evolve the design as you go.
  • You’ve got to get feedback from your customer.
  • You’ve got to stop and fix things when they come up (can’t just brush them under the carpet).
  • And you’ve got to get off your butt and talk to people.

All good things for any healthy, exciting project.

Going live becomes way less stressful

If you practice going live every couple of weeks, when the big day finally comes, it turns out to be a non-event:

  • You’ve automated just about everything you can.
  • You’ve hit and dealt with all the integration sore points.
  • You know who to talk to and what kind of coffee they like.
  • You’ve basically worked out all the kinks in the deployment process.
  • And it builds trust.

Not just between you and your customer. But between you and your team.

Once regularly producing shippable code becomes a habit to your team, it’ll just feel good. You are delivering something of value every week and your customer is seeing steady progress in a live system.

Note: This is not an excuse to stop thinking

And just to be clear, you can’t be dogmatic about this stuff.

You’ve got to look at your situation and context and decide what’s right for you, your team, and your project at that moment in time.

Pixar films don’t get finished. They just get released. – Pete Docter, the director of Monsters, Inc.

If I had to sum it up in one sentence: production readiness is doing enough work on a feature so you could release it into production if you had to.

And producing production ready code is hard

If I am making this sound all apple pie and puppy dog kisses, let me be the first to tell you—it isn’t. You’ve got a lot working against you.

First off, regularly producing shippable code changes how people and teams work. And not everyone is into change.

Secondly, you’ve got an industrial mindset (still alive and well in most companies) that believes that writing software is akin to ditch digging.

Then you’ve got unrealistic expectations, impossible schedules, and perverse incentives that all too regularly sacrifice the long term for the short.

But the good news is that it can be done, and lots of people (including your competitors) are already doing it. It just comes down to choice.

What You Need to Get There

Teams that regularly produce production-ready software usually have some combination of the following three things going for them.


In the heat of the battle, with all the dysfunction that comes with the work place, you are going to be tempted like never before to take the easy way out:

  • You are going to be tempted to not write that unit test.
  • You are going to be tempted to guess what the requirement is instead of talking to your customer.
  • You are going to be tempted to check in on top of that broken build (because you know your stuff works).

This is what separates you from everybody else. This is where the courage and discipline to do the right thing (often at your own personal expense) comes in.

Don’t expect much in the way of appreciation initially. You won’t get it.

What you will get is the begrudging respect of your peers (for having the courage to say “enough is enough”) and the self-respect that comes from knowing you produce quality work.

A Culture of Excellence

Some people aren’t used to an environment where excellence is expected. –Steve Jobs

Most people aren’t used to doing excellent work . The ironic thing is that most people want to do great work. It’s like they are waiting for someone to give them permission.

If this is you—permission granted.

You can create a culture of excellence by setting the bar high in the beginning and keeping it there for the duration of the project:

  • Don’t accept untested, poorly implemented features.
  • Don’t accept people abusing the build.
  • Don’t accept bugs—any.
  • Pair.

Setting the bar high in the beginning is way easier than trying to raise it later. Set it high at the start, lead by example, and keep it there for the duration of your project. Make excellence an assumption and it will soon become a habit.

People Who Really Care

I know you care about software. You are here, still with me at the end of this article, when you could be doing any of a thousand other fun things. It’s not you I am worried about. It’s everyone else.

You are going to need to find and track down more people like you—people who care about software, delivery, and excellence.

Finding, and attracting, people with this mindset for quality and craftsmanship is important, because when people care about what they’re doing the little things take care of themselves:

  • You don’t need a lot of rules.
  • You don’t need to write everything down.
  • You don’t need to be afraid.

Because the good people don’t need to be told what to do. They take initiative and do the right thing because they can’t help it—that’s just the way they are built.

Simple, clear purpose and principles give rise to complex and intelligent behavior. Complex rules and regulations give rise to simple and stupid behavior. –Dee Hock, founder of Visa

This is the Start

There’s a lot more we could say about production readiness. We haven’t even gotten into the software delivery practices that help us get there. But if you are still here at the end, chances are that’s not going to stop you from finding out what they are.

If your team isn’t thinking like the next iteration’s worth of work needs to be ready for battle, start fostering that culture now. It will pay big dividends later on in terms of time and cash.

And if you’re already there—good for you! Now be vigilant. Don’t get cocky. And show others how to do it. It’s a fun way to work and the more people we can get working this way the more fun it’s going to be for you and me.

Why you may find your software lacking

1 Comment

On my drive to work this morning I was listening to the excellent Pragmatic Podcast interview with Miles Forrest interviewing Uncle Bob when Miles asked Bob:

Why is it that sites like Facebook can support so many features and can be so easy to use and yet the vast majority of software systems are so ridiculously complicated and can only support a few thousand concurrent users.

“This is a very good question.” chuckled Uncle Bob.

Uncle Bob went on to explain that when you bring the people building the software closer to the people needing it good things tend to happen. Basically, agile.

And while I wholeheartedly agree with Uncle Bob’s answer, I have a few other ideas why companies like Facebook, Google, and Amazon get software right while the vast majority of us (companies) seem to get it wrong.

1. Most companies don’t live and die by their software.

For the vast majority of companies out there software is a necessary evil.

Given the choice most would rather buy their software then have to build it themselves. This attitude and lack of software expertise means most companies don’t put their heart and souls into the quality of their software and system the way say Google would.

Because these companies don’t see their software as a competitive advantage, they treat it like a deprecating asset, and let it decay over time.

2. Too many rely on QA departments.

Did you know every engineer at Facebook supports 1.2M (that’s million) users on average and they do it all without a formal QA department?

They don’t wait for someone from QA to submit a bug. Every engineer takes direct responsibility for the code they produce and works closely with operations to ensure that what they ship works, and they to support it quickly when things go wrong.

Amazon does something similar. They call it the two pizza rule.

I am not saying most companies shouldn’t have QA departments (it’s probably a good idea for the vast majority of them to be there). What I am saying is that until they start thinking about how to write software such that they aren’t needed in the first place, they are going to continue to build lousy software.

3. Too many ship their org charts.

I once worked at a start-up that had no less then six segmented, vertically sliced silos of teams each responsible for a different portion of their application. Six teams for one product.

Shipping your org chart is natural for most companies. It means you don’t have to coordinate and talk to others. You are the master of your own little silo. And your bonus certainly isn’t contingent on someone else meeting their goals.

Microsoft is currently falling prey to this. As Ray Ozzie recently pointed out in his farewell address to the company, Microsoft runs the risk of being left behind unless they can get their act together and start shipping integrated products beyond the PC. The have to stop shipping their org chart.

4. Most don’t see the value of software talent.

I know this sounds obvious but the quality of your product is directly proportional to the talent of the people you have building it. This cliche is compounded x10 when it comes to software.

Contrary to popular belief software is more then just typing.

You don’t have to explain this to companies like Microsoft, Google, and Facebook. They are currently locked in a waging war for talent. Anyone doubting the impact a single developer can have should ask Google where GMail, Googletalk, and Googlenews came from.

Google Making Extraordinary Counteroffers To Stop Flow Of Employees To Facebook

So that next time someone asks you how Google can organize the worlds data, and your company can’t seem to push a single release of their software live, check the size of your companies QA department, see if your company is shipping their org chart, and ask yourself if you truly live and die by the quality of your software.

What bug tracking system should we use is the wrong question to ask


Some times when you are kicking off new project you will hear people debate whether we should be using this tool or that. This could be everything which IDE is better (a classic) to which type of wiki to install.

Recently I witnessed a passionate discussion between the developers and QA over which tool they would use for bug tracking.

This is the wrong question to ask.

Instead of asking themselves how they are going to track bugs, teams should be asking themselves what they can do to avoid having any in the first place.

* Make the goal of your project not to require a bug tracking system.

* Don’t accept that bugs are going to be a part of your project.

* Make yours the first bug free project your company has seen.

That way no one will care how you track bugs because you won’t have any to track.

Then you can take your savings and enjoy an evening (or afternoon) at the pub instead.

beer More

%d bloggers like this: