The art of Fewer

May 12th, 2010 in Micro Blog. Weblog

Tools I know that less is more, or at least I thought I did. Fewer features, fewer hours, fewer employees, it all seems obvious. And yet, I am surprised each time I see it for myself.

Less debt is good

Cutting features from an existing tool or not building them in the first place is a fun platitude. It strokes our sloth (programmers are lazy bastards) and boosts our ego (we’re smart buggers too). But doing it, and actually seeing the contrast, is incredible.

I’m working on a web tool that has an API and a couple of handheld apps. I’ve fought to keep it small and simple, but feature creep is sneaky, and we added a few features that were not related to the core of the thing, but that we thought we had to have.

One of those sneaky features was a simple help system. It wasn’t much more than a handful of tables and a few views, a week or two of development at the most. The problem with these features is that it wasn’t enough. It still needed search, better organization, a few bug fixes, and more–well, you get the idea.

We built something that had an obligation attached to it. Our help desk had to be useful and attractive. And to do that it needed a few more things, which in turn needed to be tested. The first few weeks of development doubled in size after only six months of development. Debt can suck.

Not all debt is bad, of course, but support software isn’t something we do better than anyone else, and it isn’t related to our product.

I stripped the feature out and replaced it with an excellent online service. The new tool took only a day to integrate, and it has many more features than we would have ever added ourselves. Best of all, it’s run and maintained by people that really dig support, so we know it will only get better. That’s one debt gone, and one investment added. We will get more for our money, as their tool improves.

The cost of an unbalanced BMI

We are between products right now and our market is really struggling. We know that this happens in business, so we planned carefully and adjusted the size of our business to match. What I didn’t expect was how much more productive everyone would be with fewer people to do the same amount of work. And I was blown away by how much easier it is to say no, when everyone was aimed in the same direction.

So what happened after the dust settled?

  • There were fewer conflicts and distractions
  • Those that remained were experienced enough to manage themselves
  • It was much easier to share a single vision
  • There was less planning, fewer meetings, and more doing

We’ve all read and digested Brooke’s Law. We know that networking people degrades exponentially, and that they also add mass and the chance of negative momentum. And yet we add people with low multipliers because the work must be done.

It’s another example of fewer is better, which plays especially well with fewer features and less complexity. Fewer features require fewer people to build, implying less maintenance over time. Fewer people cost less and can move more quickly, sometimes exponentially.

This day has 22 minutes

With fewer people and fewer features, there is more time left in each day. But what do you do with more time? You do less, of course, which means you’ll get more done.

With my largest team there were days where I was interrupted several times an hour. There were days where an hour of real work was a great day. Looking back I wonder how I could have thought that an hour a day was okay. It wasn’t, and it’s not. I should have said no, split up the team, and fired the losers.

Even with my last team, which was much smaller, I was interrupted a couple of times an hour. I compensated by working more, mostly when the team wasn’t around, and often correcting their mistakes or working around their misguided (often by us) designs.

With a couple of interruptions an hour, each averaging 10 minutes, I was running at about 50% of my normal capacity. I was also more rushed (I have to get this finished before today’s scrum), and much more forgetful (what was I doing before that call?), which are added to the raw duration of the interrupt. For an average team size it meant 20-30 minutes of real work per hour, for the larger teams I sometimes hit a low of 20-30 minutes of real work per day.

Compensating with more hours eats away at inspiration and creativity, not to mention health and family. More features, more people, and more hours burn people out faster. I’ve been burnt out many times, and it’s hard to come back.

Less and fewer are better and better

Don’t forget how less multiplies out, each factor affects the next. More people? More features? More bozos? More debt? It’s all negative in a way that kills a business.