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.
3 Comments
Nice idea and I also find pruning can be immensely satisfying.
What can be taught at smaller scales is that rather than hacking out reams of code like the NsIProcess cmd line stuff, you should research until you find the simplest solution using existing functions, classes etc. Ok so that’s not so heroic and makes no impression on anyone using lines of codes metrics but it makes immensely more reliable and maintainable code.
Cheers
Hey Dave! What you describe is exactly what I recommended to a similar industry/academic advisory committee at another Ontario college – ages ago. That program is defunct now, I’m sorry to report, but in its hay day turned out some talented grads, a few of whom were hired into a fairly lengthy and large (LOC) telecom project upon which I worked.
This academic program was not unique in turning out grads who thought they’d be coding from scratch in a large project their first year out of college or university, but they were the ones whose ear I had. One of the suggestions was that some of a year’s projects (which were, like yours, joint undertakings with commercial organizations) consist of continuing on with a project from the year before rather than starting from scratch – preferably one that was incomplete (I’m evil, I know!) but adding functionality to an existing one counted, too.
I was pleased to see my suggestion implemented the next year. I don’t see how else the skills that “working to scale” engenders can be taught except as you are already – a joint project with industry players. As Steve mentions, it’s not all about glory out there in the ‘real’ world. Dare I say that more often than not, a new grad’s lot on a large project will be cleaning up, refining and improving on what’s been done by others. Some folks actually enjoy this as much as creating something from nothing. I know I did
And, sometimes huge benefits for the team and product codeline can be realized as a result of work that’s undertaken from such a starting point. If they are smart, project leaders won’t let this go unnoticed.
I still maintain that fixing others mistakes (bugs) can be a fantastic training foundation for a programmer. No faster way to learn what *not* to do, IMO. The stumbling block for your program will be gaining an ‘in’ with entities who have a large code base that will be going through several iterations and will allow students to work on it.
One barrier I found for undertaking these ‘cleanup’ projects inside a company was funding. There’s sometimes (okay, often in my experience) difficulty convincing the bean counters and project managers that it’s a worthwhile investment since no immediately tangible benefit can be seen (by them at least). I used this as a foot in the door to gain interest for such projects within the company back then. It might work for you, too.
Best of luck with your excellent program.
PS: as incentive for student programmers I’d like to add that sometimes ‘rework’ projects can have surprising, if unintentional side-effects for those engaged in them. Like patents.
With the move we have done from tinderbox to buildbot to do the L10n repackages we have basically got rid of pages of code (tinderbox client) to use just simple “make targets” under buildbot.
We still had to write some new code to do things that we have never been done before (creating multiple build objcets – one per locale) but it is a pleasure to remove pieces of code that were just making everything too complicated.
2 Trackbacks
[...] everything that he talks about is applicable at a place like Mozilla, where we have to work at a larger scale than they do at 37 signals, but there’s a core here that we share about action, simplicity [...]
[...] have a minute to make an observation. I’ve spoken in the past about what it’s like to work at scale with a project such as Mozilla. Yesterday I was reminded of this again, but for a different [...]