Irreal

As I’ve said many times, management is a necessary part of any successful business, especially any large business. After all, someone has to set the goals, make all the mundane decisions, and do all the politics that would bore an engineer to death. That said, there’s a certain type of manager—usually coming from the finance side of the business—that are mainly good at destroying companies. They focus on financial metrics such as stock price and almost always have a poorly hidden contempt for those who make whatever it is the company is selling. They are, they believe, the ones in the know. The only ones who know how things work.

The poster child for this is, of course, Boeing where the finance suits turned the world’s premier aircraft manufacturer into a company so bad at making aircraft that many laymen—let alone those in the business—refuse to fly in them.

Another, less drastic example, is Bell Labs. The Labs were a national treasure inventing things like the transistor, lasers, and, of course, Unix. There was much more as I mentioned in this post. That all ended after divestiture. Our national treasure was destroyed almost immediately by the new management. The Labs still exist—sort of—but when was the last time you heard of them doing something spectacular.

Over at The Unix Heritage Society (TUHS), there’s been a recent discussion over where the 20% rule—the policy that employees could spend one day a week working on their own projects—originated. The consensus appears to be that HP had been doing this for years and was probably first. Of course, the discussion soon devolved into the level of control exerted on engineers at various companies.

Rob Pike—one of Bell Labs stars from the old days—chimed in with this post. The gist was that there was little supervision or direction—at least in the Research department—as long as people were delivering value. Pike offers this explanation for why he left:

The main reason I left the Labs was a change in management resulted in
insistence that I work on things of no interest to me, things that didn’t
even align with my skills, and deliver that message to the people reporting
to me. A complete failure to understand what had made the place so
successful.

Ken Thompson expressed similar sentiments in this oral biography:

It had changed; it was really different … You had to justify what you were doing, which is way above my pay grade.

It is, once again, an example of suits being completely oblivious to the value of the treasure entrusted to them and having no idea of what made it so valuable and successful. It’s easy to say that these organizations need close supervision if they’re to be successful and bring value to the company. The Labs reveal that for the nonsense that it is.

Most serious Emacs users are familiar with Bozhidar Batsov. He’s a blogger and the developer/maintainer of several OSS and Emacs projects such as RuboCop, CIDER, Projectile, nREPL, and many others. And, of course, he has a full time job. That brings up a question that Batsov says he is often asked: “How does he find time to work on all these projects?”

He answers that question in a recent post on his (think) blog. The secret, he says, is “burst-driven development”. By that he means that while he may keep an eye on his bigger projects he will only work on one or two at a time in a burst of effort. During those periods, he may work on a project furiously for several days or weeks and then move on to something else. The important thing for him, he says, is to not try to work on several projects in parallel.

This type of schedule may seem less than optimal for project development but Batsov has learned a few things that suggest it’s good enough:

• Few problems require immediate action
• There can be times when you don’t have any good ideas for improving a project
• Sometimes a project is simply mostly done

That last item is especially telling. Often I’ll see complaints about some project saying that it hasn’t had any updates for a long time. But sometimes a project solves the problem it was written to address and there is little to add other than keeping up with OS changes or something of the sort.

In any event, if you want to see how a prolific developer handles his projects, take a look at Batsov’s post.