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.


  1. I thought quantity has a quality all its own? ;-)

    Seriously, though, I'm not sure if "quantity vs. quality" is the exact right way to frame the tension here, but I think I know what you mean... Seem like you're setting up a tension between:

    crafting elegant code (maybe you're equating "elegance" with "quality"?)


    hacking a whole bunch of components together to create a full-featureset (maybe you're equating "a bunch of components together" with "quantity"?)

    Framed that way, I guess you could validly assert that different engineers will derive satisfaction from either side of that spectrum. E.g., some folks really enjoy solving very specific problems in an elegant fashion. While others will get maximum satisfaction from producing a working finished product (even if there were some wonky hacks employed along the way).

    Either way, though, the dimension of "elegant code" vs. "code that just works" is orthogonal to the amount of usage that a piece of code gets. E.g., a chunk of elegant code that gets seen and used a lot by other members of a team is much more satisfying to build than a similarly elegant section of code that never sees the light of day. Knowing that your code (elegant or hacky as it may be) gets used a lot is the feeling of "making a difference" that unites all engineers. This is almost a tautological argument -- by definition, "engineers" are practitioners who apply knowledge in the production of real world products and services that meet the needs of society. I, for one, would claim that any coder who doesn't think that way isn't really an engineer per se.

    That's not a knock on any great coders who are happy to toil away on ultra-elegant solutions to big problems! Just don't call that "engineering" -- that's more akin to basic research. :-)

  2. You make a valid point - "engineering" has in its definition applying one's knowledge to the real world.

    There's still a beauty though in a building that never gets lived in. It's ultimately the real estate developer that derives joy from the building being inhabited, not the architect.