motto lotto

Saturday, January 17, 2009

dirty systems

This essay does a good job of describing an obvious divide between types of computer scientists (and technology workers more generally).
Theorists Favor Sophistication

Like mathematicians, theorists in Computer Science take the greatest pride in knowing and using the most sophisticated mathematics to solve problems. For example, theorists will light up when telling you that they have discovered how an obscure theorem from geometry can be used in the analysis of a computer algorithm. Theorists focus on mathematical analysis and the asymptotic behavior of computation; they take pride in the beauty of equations and don't worry about constants. Although they usually imply that their results are relevant to real computers, they secretly dream about impressing mathematicians.

Detecting Theory

You can tell someone is a theorist because they slip one or more of the following keywords and phrases into lectures and technical conversations: ``theorem'', ``lemma'', ``proof'', ``axiom'', ``polynomial time'', ``logarithmic'', ``semantics'', ``numerical'', ``complexity'', ``nondeterministic'' or ``nondeterminism'', and ``for large enough N''. They write lots of equations, brag about knocking off the ``extra log factor'', and often end their lecture with an uppercase ``O'' followed by a mathematical expression enclosed in parentheses. You can also recognize a theorist because they take forever to prove something that may seem quite obvious. (I once sat through an hour lecture where someone proved that after a computer executed an assignment statement that put the integer 1 into variable x, the value in x was 1.)

Experimentalists Favor Simplicity

Like engineers, systems researchers take pride in being able to invent the simplest system that offers a given level of functionality. For example, systems researchers will light up when telling you that they have constructed a system that is twice as fast, half the size, and more powerful than its predecessor. Experimentalists focus on the performance of real computer systems; they take pride in the beauty of their code and worry about constants. Although they usually imply that their results can extend beyond real computers, they secretly dream of filing patents that apply to extant hardware.

Detecting Systems

An experimentalist will slip one or more of the following keywords and phrases into lectures and technical conversations: ``architecture,'' ``memory,'' ``cpu'' (sometimes abbreviated``CISC'' or ``RISC''), ``I/O'' or ``bus'', ``network'', ``interface'', ``virtual'', ``compile'' or ``compiler'', ``OS'' or ``system'', ``distributed'', ``program'' or ``code'', and ``binary''. They talk about building programs and running the resulting system on real computer systems. They refer to companies and products, and use acronyms liberally. Their lectures often end with a graph or chart of measured system performance. You can also recognize an experimentalist because they describe in excruciating detail how they set up an experiment to measure a certain value even if the measurement produced exactly the expected results. (I once sat through an hour lecture where someone carefully explained how they used three computer systems to measure network traffic, when their whole point was simply to show that the network was not the cause of the problem they were investigating.)

How To Criticize Computer Scientists
A mixture of both is probably best but life is messy and simple solutions are easier to maintain. That means if you do it right a non-technology person (or at least someone with a weaker skill set) may be able to perform that task once completed. So I'm an experimentalist and I value experience. You'd think that theorists are best suited for true programming jobs and that experimentalists are best suited for systems administration but programming often requires integration with various systems. Most of the time (unfortunately) technological solutions aren't built to match theory (they rarely meet specifications, see how well browsers meet w3c or even http specs for an obvious example). What this means is that in practice the "perfect" theoretical solution won't work. Someone else will have to come by and accommodate the clean code to integrate with the dirty systems. Dirty systems will often negate the performance increase gained through the "optimal" theoretical solution as well.

Incidentally, a lot of interviews for programming jobs lean toward the theorist side so it's best to memorize a bunch of rarely necessary crap (O Notation, obscure data structures, better to reuse code or reference the appropriate books when necessary in the real world) before going into those sorts of interviews. I get the feeling interviewers test the theorist side just because it's simpler to test.

Both of these descriptions show how each side can get caught up into details that distract from the problem at hand and having both types on a programming team is usually preferable.

The philosophical point: Humans are dirty systems and they're the systems that we never get away from. So you can either accommodate this truth (experimentalists) or ignore this truth (theorists). Perhaps these correspond with empiricism and rationalism.

No comments: