Thursday, July 7, 2011

Code components not features

A few days ago, I asked one of the "grey hairs" (experienced people) at my startup:
Is it better to have engineers coding features or components? Should they work on a vertical slice, a feature, that cuts through many layers in the technical stack? Or instead, should they focus on one component in one layer of the stack?

I wasn't sure of the best answer, but the experienced-one recommended a one-engineer-per-feature approach, especially for a startup. His argument cited greater individual motivation, higher functional quality of the feature, and faster iteration on the feature.

They say an easy way to make a 50/50 decision is flipping a coin, and if it comes out heads and you're disappointed you know you should have decided on tails. So let me try to make the opposite case: you should always have engineers work on just one particular component, in one layer of the stack, and never on an entire feature.

When you have a system, whatever system that might be (a company, a technology product, a team of people), the system will naturally have a tension between the goals of the individual parts of that system and the system as a whole. For example, the star hitter on a baseball team might want to go for a homerun everytime to improve his stats. But sometimes, it's best if they only go for a single because the team needs another man on base.

A tech startup has two big systems: the product itself and the team creating the product. Happier teams make better products so we'll focus on optimizing the "team system" first. Where the post linked above goes wrong is here:
Nothing is more motivating than feeling like your work really makes a difference.
Programmers, however, aren't motivated by quantity they're motivated by quality.

The quality of one's work is directly tied to one's self-esteem a trait inherent to human nature. A piece of code that is executed by a processor 750 million times isn't necessarily higher quality than a piece of code that is executed only once.

The very idea of a startup is a perfect example of this principle. When you're writing code at a startup it will likely get used by no one at first. So the only motivation you have is making something that is high quality.

Since about 1960 the software world has agreed that producing high quality software requires breaking a system down into smaller parts. This isn't too surprising given the way large systems (like countries and corporations) have always been organized.

It's easier to make one thing of high quality than ten things of high quality. And while an engineer might enjoy creating more rather than fewer high quality things ("Yay! Big contribution, I know I can do a good job on all of them!") it's going to be best for the system (the team) to have each person focus on making at least one thing of high quality first.

This encourages better encapsulation, abstraction, and in the end a better product which can go on to lead a company to becoming the second biggest in the entire world. It comes down to a focus on quality first and all else second that wins the day.