Sunday, June 25, 2017

Software Engineering Maxim #2: Enthusiasm improves productivity.

(This is the second in a series of Software Engineering Maxims Which May or May Not Be True, developed over the last few years of working at Google. Your mileage may vary. Use only as directed. Past performance is not a predictor of future results. Etc.)

By far the best way to improve engineering productivity is to have people working on something which they are genuinely enthused about. It is beneficial in many ways:

  • the quality of the product will benefit from the care and attention
  • people don’t let themselves get blocked by something else when they are eager to see the end result
  • they’ll come up with ways to make the product even better, by way of their own resourcefulness
  • people are simply happier, which has numerous benefits in morale and working environment.

There are usually way more tasks on the project wish list than can realistically be delivered. Some of those tasks will be more important than others, but it is rarely the case that there is a strict priority order in the task list. More often we have broad buckets of tasks:

  • crucial, can’t have the product without it
  • nice to have
  • won’t do yet: too much crazy, or get to it eventually, or something

The crucial tasks have to be done, even the ones which no-one particularly wants to do.

In my mind, when selecting from the (lengthy) list of nice-to-have tasks, the enthusiasm of the engineering team should be a factor in the choices. The team will deliver more if they can work on things they are genuinely interested in doing.


Saturday, June 24, 2017

Software Engineering Maxim #1: Small teams are bigger than large teams

(This is the first in a series of Software Engineering Maxims Which May or May Not Be True, developed over the last few years of working at Google. Your mileage may vary. Use only as directed. Past performance is not a predictor of future results. Etc.)

In my mind, the ideal size for a software team is seven engineers. It does not have to be exactly seven: six is fine, eight is fine, but the further the team gets from the ideal the harder it is to get things done. Three people isn’t enough and limits impact, fourteen is too many to effectively coordinate and communicate amongst.

Organizing larger projects becomes an exercise in modularizing the system to allow teams of about seven people to own the delivery of a well-defined piece of the overall product. The largest parts of the system will end up with clusters of teams working on different aspects of the system.

Monday, June 12, 2017

Resurfacing

I've spent the last few years working as a software engineer and manager at Google Fiber. It was interesting work, but did not leave a lot of time for writing. As I now have more time available I'll make an effort to start writing again. I regret leaving it aside a few years ago.