It's a bird, it's a plane, it's

Everything here is my opinion. I do not speak for your employer.
August 2004
October 2004

2004-09-25 »

Management Architecture

To avoid the worried feeling I get about a recent directive from top management to effect of "Do everything possible to trick Avery out of writing actual code, because he's most useful doing other things," I've been trying to make my own job seem more attractive. (That's the actual quote, by the way. There is no directive to me, only to other people. I love this company :))

So here's my latest attempt: in a parallel with the similarities I noticed between programming and People Hacking, I've noticed a similarity between code architecture and company management structure. My latest theory - and the coders at NITI will be familiar with the results of this by now - is that a manager, like an object, should do just one thing, and do it well. If it takes you more than a sentence to clearly explain what your manager does, then his job is not clearly defined, and sure enough: he'll do it badly.

So, after the OO fashion of the moment, we've been trying to rearrange our management structure on a functional-block basis instead of using a pure inheritence hierarchy. For example, the new Pusher job (no link yet, sorry) is "responsible for when a release comes out." The now-simplified Visionary job (well, that link is for EvilVisionary, but you get the idea) is "responsible for what goes into a release." Best of all, you instantiate a new Pusher for each release, but they all communicate with the singleton Visionary object, er, person, who can move features around between releases.

Consider what the pusher does when your release is late:

  bool ok = visionary.drop_features(release, 5 /* days */);
  if (ok)
     return true; // on time again!
  else
     release.duedate += 5; /* days slipped */

I think pphaneuf will agree with me when I say that there needs to be one object at the top that ties it all together by setting up the initial objects, but it should probably be about ten lines long and do almost nothing.

Okay, I'll stop now.

2004-09-29 »

Scripting Languages and Reliability

Since I've said this to several people at work in the last few days and nobody has had the heart to disagree with me, I will now open myself up to public flaming and see if that helps.

My assertion: it is totally impossible make really reliable, high-performance programs (like oh, say, idb backup) in a language other than C/C++ (and maybe ADA and C#, but I'll reserve judgement for now). This includes, but is certainly not limited to: python, perl, shell, java, tcl, and php. Especially python. And really especially PHP.

My evidence: nobody has ever written a reliable, high-performance program in any of those languages.

Thank you. Have a nice day.

August 2004
October 2004

I'm CEO at Tailscale, where we make network problems disappear.

Why would you follow me on twitter? Use RSS.

apenwarr on gmail.com