Nicholas Carroll
May 12, 2000

These secrets date from the stone age of software. They seem fresh, though, every time I see a completely blown project.

GIGO

When computing time was expensive, both programmers and management were fairly well agreed that programs ought to do something useful. The time to do cool hacking was 3 a.m.; daytimes were for running payrolls, crunching financials, or evaluating the tensile strength of a given I-beam.

Today computing time is so cheap that receptionists can use a spreadsheet program to create office forms. (Actually, this is a very sensible use of PCs.). But in between the receptionists using their PC for common-sense tasks, and the real programmers doing critical work, lies a vast army of clueless managers, many computing for the sake of computing.

The old rule still holds: if you don't know why you're doing it, it's probably not worth doing.

(Walk through a modern computer conference offering $100 for the definition of GIGO, and you may still have your money at the end of the day.)

Structured Code

Bwahahahaha! That was pretty funny, and I just wrote that quote myself.... No, I didn't fall on the floor, but my eyes are tearing a bit. Excuse me ... OK, I'm back.

"Structured code," once considered inherently good, is now ranked with grammar, as something for old farts. Still there are benefits to structured code:

Other programmers can understand it later on.

It's easier to debug, easier to clone, and easier to scale. These things add up to big savings in time and hard cash.

It's usually faster, as it tends to call the processor and storage in more logical sequences, with less backtracking.

The opposite is "spaghetti code." The name pretty well describes it; it winds all over the place, like a book that doesn't have the chapters in sequence. If it's messy enough, the next programmer to work on it may have to re-write the code from scratch, finding that faster than untangling the spaghetti.

One rarely gets spaghetti code from programmers who have written in C or assembly language. These are low-level languages, that demand some understanding of how a computer works, and the programmers learn discipline. Programmers who only know high-level languages like Perl or Visual Basic are far more troublesome.

(Though Visual Basic is considered the sick cousin of real programming, VB programmers are not necessarily the most troublesome breed. Many of them are self-taught, and learned their craft bit by bit on the job, addressing business needs, so never learned to produce bloatware.)

Prototyping

While a small business accounting system can be set up out of a shrink-wrap package, and it will be reliable if unimaginative – a larger or customized software system is a completely different animal.

There are basically two choices in prototyping:

1. Design a mockup, talk to the people who will be using it, mull it over, design the semi-final, and get to work testing the concept, code, and interfaces. Call it, say, $100,000.

2. Quit beating around the bush. Design a working model, build it, and get rolling. Now you have a $2,000,000 prototype. May your company survive it....

Modularity

Humans are not watchmakers. When systems become both technical and complex, intuition fails. We need to understand such things at an intellectual level first. Understanding a software system usually means you can put it on paper - not as a swirling mess of bizarre symbols and curling arrows, but as a nicely spread out group of modules.

Thus words like "seamless" and "dynamically generated" should arouse suspicion - as should practices such as mixing code and data. (C++ was a good experiment - programmers learned a lot from it. However von Neumann architecture - separating code and data - has yet to be improved on. In a hightech world gone mad for object-oriented programming, good old procedural code is still the lean mean machine.)

Test it in parallel

I've known some extremely well-run businesses which were driven into bankruptcy because they didn't know this rule.