Glad You're Ready. Let's Get Started!

Let us know how we can contact you.

Thank you!

We'll respond shortly.

  • Blog Navigation
Priorities and Speed

Working for Pivotal Labs is different than any other software shop I know. A big part of this is that it is easy to feel good about the product you’re delivering to your client. Another reason is that we constantly challenge our own practices, ensuring that we continue to do the right things for the right reasons.

Let’s assume Pivotal Labs emphasizes these things in this order:

  1. Code Quality
  2. Product Quality
  3. Speed of Features Released

Whereas a typical client may want this ordering:

  1. Speed of Features Released
  2. Product Quality
  3. Code Quality

It made me raise my eyebrow. First, this is a totally expected response to making code quality #1. I’ve been in those fights where devs want to refactor, and management wants a feature. It also could get under my skin that someone thinks that delivering features was “low on our list”. Then I thought about “why”.

We do deliver features quickly. Faster than any other place I know. This is true across all three projects I’ve worked on, and I assume all projects at Pivotal Labs. But the reason we can do that is largely due to code quality and concerns for product quality.

If my code was crappy, and patched, and buggy, and untested, each feature I’d add on would make the problem worse. And while it is true I could deliver the first few features this way with great speed, I can’t sustain it for long at all. Delivery speed drops off exponentially as time progresses that way. But if I refactor, write tests, and do my best to write good code up front, I can sustain that, even make incremental improvements as I go and deliver more features in the same amount of time.

Product quality focus also helps speed in a less direct way. If sheer number of features was indeed my focus, then my team may crank out features X, Y , and Z this week. When X,Y, and Z go public though, we may find that no one wanted Y, and Z, and so we wasted our time doing them when we could have been adding the killer feature that people did want if we had only “slowed down” and asked those questions of our product owners. In this way we don’t deliver “more” features, we deliver higher value features, meaning that the client gets a lot more bang for his buck.

Code quality is what we do. It enables us to deliver more features over time. Product quality lets us deliver better value. Together, they take care of the “speed” request that every client has.

  • Well put, Will.

    I ran into a similar situation recently, and wrote something about the code-level tradeoffs:

    But you’re right, it’s equally true at the product level.

  • When managing a distributed team, any ideas for how to keep code quality high? I’d love to find a good way to do remote code reviews.

  • Chad Woolley

    @joe – use Test Driven Development and Remote Pairing for your distributed teams. It is much harder to write poor code when you TDD, and pairing is constant code review. See [my article]( for some tips on remote pairing.

  • Will Read

    @joe – backing up what Chad has to say, pairing and TDD are the best tools out there for that kind of thing. But developers need **support**. The other piece about Pivotal is that our CEO and our Principles set up an environment where it is *expected* that we take time to tend to quality.

  • Erik Hanson

    Joe: I agree with the others that pair programming is a superior way to do code reviews, but I realize that for whatever reason, sometimes pairing is not possible.

    I’ve worked on a couple projects with distributed teams who didn’t pair. On one, we used a home-grown web-based tool along the lines of [Code Collaborator]( or [Rietveld]( It was better than emailing diffs around, but it was still painful.

    On another project, we were supposed to use Code Collaborator, but we instead just called each other on the phone (or skype), shared our screens with VNC, and talked about the code. This kind of review was so much more useful. Phone calls are much higher bandwidth than text annotations on some code, and especially for a distributed team, having some regular contact with other members of the team is really useful. Also, code reviews can sometimes seem antagonistic — in text, it’s hard to know if “why did you do X?” is accusatory or just simple curiosity. I highly recommend this approach.

Share This