Priorities and Speed

July 13, 2009 Will Read

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.

About the Author

Biography

More Content by Will Read
Previous
Tweed Update: v0.9.10
Tweed Update: v0.9.10

A new version of Tweed is available! (v.0.9.10) Bug Fixes if you view a timeline, it will clear any pendi...

Next
Webcast: Unit testing with the Palm Mojo SDK
Webcast: Unit testing with the Palm Mojo SDK

Next Tuesday, July 14, at 10pm PST, Chris Sepulveda from Pivotal Labs will be broadcasting an O'Reilly WebC...

How do you measure digital transformation?

Take the Benchmark