The Changing Value of Development Speed

An Interesting Poll

I recently asked this question on LinkedIn:

The reason that I asked this question is somewhat interesting.

A Trip to the Past

Back in a previous life, I worked at Borland. For those of you who don’t remember, Borland was at one time a pretty famous software company, competing directly with the Microsoft Languages and Office divisions. Borland is probably most famous for their C++ and Delphi products. In the nineties, they built a beautiful building in Scotts Valley, CA. Their end (as signified where the link above goes) is a story for another day, but suffice it to say that at one point, Borland was on the tips of people's tongues much like Microsoft is today.

Anyhow, Borland had an enormously successful product called JBuilder, the first commercial Java development tool. On the R&D team for JBuilder was a developer – let’s call him Jack – who was notorious for being two things: slow and immensely good. He took a long time to get things done, but his code was, for all intents and purposes, bug-free.

Members of the QA team would try to find bugs in what Jack wrote, but it was very difficult to do. A QA Engineer would consider it a badge of honor to spot a bug in code that Jack wrote.

Sure, he was slow, but as I said, the downstream cost of Jack’s code was very low. Bugs are expensive and time spent fixing bugs is time spent not creating new features. Jack spent a very small amount of time fixing bugs because he didn’t write them in the first place.

Now I give full kudos to Jack’s manager who recognized the immense value of what he could do. It would be very easy for a manager to focus on the “slow” part and not realize the value in the “almost no bugs” part. The total cost of ownership over Jack’s code was actually much lower than his teammates who, while great and faster developers, couldn’t match his level of initial quality.

Back to the Question

Which brings us back to the question I asked.

I asked the question because Jack had recently come to mind in a discussion, and it got me thinking. In today’s development environment, I’m not at all sure that Jack’s unique skill would be as valuable as it once was.

Jack coded in a very different environment than developers today. JBuilder was shipped once a year or so. There were periodic bug fix updates, but new features were generally only delivered annually. The software development process was basically Waterfall – product managers would define requirements, the team would architect and build the features, QA would test, formal beta tests would be run, and the product would ship in one big, grand release.

Now the second half of that equation – all the testing – was pretty time consuming and thus expensive. Having a developer that minimized those costs was very valuable.

But in today’s world, those costs are not as high as they used to be. The advent of CI/CD and a SaaS software solution drastically reduces the cost of a bug.

In the old way, a bug would frequently linger in code for weeks or even months before being discovered. As we all know, the larger the distance between keyboard and bug discovery, the more expensive the fix. The longer the time, the lower the chances that the developer will remember anything about the code she wrote that caused the bug.

But with modern tools like Rollbar, a developer can usually find out about a bug in his code in minutes or even seconds. If a bug is found that fast, the code is still fresh in the developer’s mind, and fixing the bug can be quick and painless. Rollbar can even pinpoint the exact line of code that caused the error.

Fast Feedback and Rapid Response

Now if the feedback loop for a bug is measured in minutes, then I think developers should be encouraged to truly “move fast and not worry about breaking things.” Developers like Jack are still valuable, I suppose, but being slow actually can become a liability. His high-quality code saves a lot of downstream time when you release annually, but when features can be released at any time, and when feedback loops are measured in minutes, a fast developer can often get more done in the same or less time.

For instance, say Jack takes two weeks to develop a feature that our faster developer (let’s call her Sara) can finish in one week. Sure, Jack’s code is flawless, but Sara’s code is pretty good, and she only needs three days to see and fix bugs as the code is tested under a feature flag with beta testers. That means Sara is able to produce what Jack produces with two days to spare.

Changing Development Process

Development processes have changed. Debugging has changed. Tools that monitor and report on errors (think Rollbar!) can make feedback loops much, much faster than those in the world Jack coded it. We now live in a world where bugs have a much lower cost than they had in the past. Given all that, it would seem that Sara is actually more valuable than Jack.

Poll Results

So if that’s true, why the results of the poll? Why don’t people want more Saras and fewer Jacks by almost two to one?

I think there are two reasons. One, many people still aren’t rapid continuous deployment, so the benefits aren’t there for them. And two – teams probably don’t realize the fact that Sara can be more productive than Jack. It is counterintuitive, and not completely obvious until you consider it thoroughly (or just read this article!)

Wrapping up

While productive developers who produce quality code are always a necessity, the actual way that they arrive at that near perfect code changes. Tools and a different mindset about reporting bugs can make “move fast and break things” the order of the day.