[ Back to Kevin's Homepage | Back to Ramblings and Brain Farts ]

by Steven D'Angelo

The industry has changed a lot during my time working with software.

I was shocked to find out that most CSC students at Cal Poly didn't see assembly language and computer architecture courses as key aspects of their education that they had to master. Most people I saw tried to ignore those classes. But of course I'd been programming for years on systems with no support for anything higher level. I was writing drivers and even writing word processors in assembly since there were no compilers. By 1986 software was already changing from where you had to understand how it worked to understanding why it worked and how to use a high-level language to get it done.

I came in seeing a high-level language a a productivity tool, not a way to ignore the "real" issues... but changed my mind on that as we moved through. I think it's valuable to understand more, but it's no longer necessary.

By the time I got out of Poly I saw other shifts happening. Increasing hardware speeds and increased use of GUIs radically changed everything. In order to get software done at all, productivity was more important than anything else. Productivity I saw could only come from object oriented thinking. Why?

Along my way programming, I worked out some "rules" of development.

Rule #1: A program under 2000 lines of code can be put together without any skill or planning and do okay.

Possible application in teaching here... make projects over 2000 lines if you want to see if people think instead of hacking! I came up with this number roughly based on my own programs, but "tested" it on classmates and such at Poly and in the field. It seems to hold up.

Rule #2: Structured programming works on projects up to 50,000 lines but is a burdon on under 2,000 lines. For those not used to this term, it's design at a functional level.

The barrier here is harder to test. I've had projects I felt could not be handled at 30,000 lines and ones that didn't get into trouble until 80,000 lines. But the idea here is that when you track things at a per-function level and their interactions, it still gets too big for a person to track fairly quickly.

Rule #3: Object oriented programming works for up to about 200 classes. Each class is subject to the above 2 rules.

This barrier is also hard to test. But I think it's between 100 and 250 classes. The idea here is that classes are much easier to organize in the brain since they are named appropriately. People can more easily manipulate named things than sets of functions.

I laughed at OOP until I got into it for real. It was an eye opener to realize the leverage this gives you. And it has a bonus of being able to survive changes to requirements muchh easier than structured programming as well.

Depending on your class sizes, this makes projects from 75,000 to 250,000 lines well managable.

Rule #4: Modules, Layers, and Packages are ways to compartmentalize to get leverage.

I have not been able to measure the exact impact since these techniques are often best between groups or people rather than for a single person. These are the key concepts for scaling in groups.

The key point here is that the ability to organize your software is key to success far more than anything else. And if you note that many classes are less than 2000 lines, fine-grain programming skills are may indeed be less important.

All the techniques I know of to improve productivity also result in less optimized use of resources. This means bigger executables that use more memory and CPU. I'm a big supporter of the idea that optimization is rarely worth it (There are definitely exceptions here on things that run frequently) when hardware speeds increase exponentially and programmer productivity does not.

This all said, shoddy programming skills are really annoying. People who make "rookie" moves are not appreciated by their peers. What kind of moves? Repeated mistakes in basic memory management. Failure to test code to see that it actually works before putting it back into a shared code base. Etc. If you can't teach people to program well the first time, teach them good testing skills.

As for the IDE and non-IDE issue that started this thread, I personally think IDEs are great as long as you know what they are doing. I avoid them myself since they hide too much stuff that's important in real projects. Like what? Try working on a project where each programmer clicked a slightly different box and is compiling the code with different options. Yuck! And I've seen it happen regularly.

created - 2000.04.07 Steven D'Angelo
archived - 2000.04.07 kjw