oftware engineering is a dynamic and rapidly growing field, but two observations have been confirmed to be relatively constant in studies going back as far as Harold Sackman's first such study in 1968:

• The more people you have on a software development project, the more time they spend interacting with each other and trying to stay out of each other's way, and the less time they spend actually developing software.
• On most software projects, the difference in productivity between the best programmer and the worst programmer is typically a factor of 10 to 20.

The first fact is widely recognized and forms the basis for many recent programming language trends such as modular and object-oriented programming. The implications of the second fact have been less thoroughly investigated, but they should not be ignored. For example, while most operating system development projects employ hundreds or thousands of developers, the entire original and ground-breaking Macintosh operating system was written by only eight programmers! You couldn't build something like that with eight typical programmers - Apple gathered only the best of the best and gave them the freedom to work with minimal disturbances.

Now there are certainly limits to what even eight of the best programmers can do - you probably couldn't write something as huge as the Windows XP operating system with eighty gifted programmers, let alone eight. But the point is that a lot of medium-sized software development projects are being treated and organized in the same way as large projects, putting twenty mediocre programmers together, organizing them into teams with managers and semi-weekly meetings and progress reports, to do a job that could be completed sooner, cheaper, and better by five or six sharp programmers.

Scientific software development projects sometimes make even graver mistakes by dividing their teams into scientists and programmers: the scientists write prototype code or develop algorithms on paper, then hand the implementation task off to programmers who only vaguely understand the scientific problem itself. Both groups spend half their time trying to communicate concepts that the other group doesn't understand and isn't really interested in. That's not our philosophy.

Outsourcing trends have generated booming business for consulting firms, who may have a stable of programmers whom they then farm out to various clients for certain periods of time. Many folks have gotten rich running this sort of company, but our goal is not to be a body farm. We want to develop software.

Now that you know what our philosophy isn't, you may want to read about what our Business Philosophy is.