Working at scale

I was in a meeting last week where I was trying to describe what it means to work on something like Mozilla.  I often use the phrase, "working at scale," and one of my colleagues stopped me to ask just what that meant.  Explaining it without examples is hard, so I thought I'd give an example to illustrate what I'm talking about.

In teaching programming we make an implicit assumption: programming, let's rather call it development because of the helpful denotation it provides, is about building things with software.  It is creating, adding, enhancing, writing.  Development, as taught in post secondary institutions is a creative act, whose output is measurable in LOC (i.e., lines of code).  And if you'd like to argue with me, ask yourself how many student assignments and projects contain a function called main() that they have written themselves.

Now, Mozilla development--and I speak of Mozilla because this is what I know, but substitute another mature, large open source code base--is about never writing main().  Obviously someone has written it, and this is why the rest of us do not.  It is about sewing new patches on an already existing quilt, attempting to have the inclusion disappear into the whole.

"OK, so you don't write the whole program yourself, you add bits here and there, that's still the same thing."  But what if you didn't add?  What if you subtracted?  What if programming meant, instead of making more, making less?  And what if this making-less was viewed as a first order contribution to the whole?  What if someone added to the whole by removing things?  I don't think this concept makes any sense in the way we currently teach development.

Let me show you what I mean.  One of the first times I had Mike give a talk in my class, he told them that good patches remove more lines than they add, and they all laughed at the idea that I'd accept a project that just deleted things.  I would.  Take the work James is doing for his 0.1 release, with a patch to fix nsIProcess which removes 231 lines and adds 15.

Now take the work that Taras is doing to find and remove statically dead code.  He and I were talking the other day about how we really need to teach people how to remove code, how to write less, how to do more with what is already there, and above all, to avoid adding whenever possible.

These are ideas that make no sense unless you're working at the scale of Mozilla.  You can't remove something from nothing, you can't pare back main() and still have something to show.  The kind of programming I love--gardening, editing, trimming, tidying--is the sort of thing you can only do at scale.  You need a lot of code in front of you before you can start honing your use of scissors.

Why don't we teach this?  Is it because we're afraid to work at scale with our students?  Are we afraid ourselves?  Or is there not enough glory in the kind of programming I'm describing?   Whatever anyone else says, programmers like James and Taras, who've learned how to work at scale, have it right.  I think we need to get serious about teaching the next generation of developers how to do this.