Why so weird?

Some of the coding tips you will see are not common practice. That is to be expected since there is not much written about coding (as opposed to managing or designing) large programs.

It is my belief that the coding of large programs has to be tackled differently than that of smaller programs. It should not be very surprising - after all, lots of people believe that large programs need to be designed or managed differently (at least more systematically) than small programs.

The definition of a large program varies from field to field. For instance, in the systems area (e.g. compiler, OS), I would call a 150,000+ lines of code program . I would also call a 100,000 lines of code hard real-time program large. I would comfortably call any program over 200,000 lines of code large.

A project that implements a large program takes about 2-5 years to finish. That means that over a 20 year period, a person can typically work on 5-6 large projects, assuming, of course, they don't switch projects mid-way.

Also, the majority of people coding these programs do not code enough of the program to understand the complexity of the task, figure out solutions to reduce that complexity, and then test their solutions. I suspect that a person needs to code at least 100,000 lines their-selves of a large project before they can truly start coming up with solutions that mitigate the complexity that arises from the size of the project.

How many times do you think a senior programmer contribute 100,000+ lines of code to a large projects in their career? I think the answer is some number between 0 and 2. Most people can't code that much. Of the ones that can, they

I've worked on 4 projects of over 200,000+ loc, where I contributed over 100,000+ loc. I've also written solo several programs in the 50,000 to 100,000 loc range. Over that time, I've tried to develop techniques that systematically attack the problems that I have encountered.

Keep that in mind when you read the following tips. They are designed to solve problems that become really serious at larger program sizes. That is why they may look so weird.

Idle speculation: is the reason that there are so many books about methodologies and managing, designing and architecting large systems, and so few about coding them because all the "experienced" people are busy being consultants/managers/designers/architects as opposed to programmers?
Next Prev Main Top Feedback