Re: Random quotes in the top left corner

[mr_mischief]

The KISS principle has been around longer than Perl. It's a great thing for any programmer to remember, or any engineer, any web page designer, any cabinet maker, any essayist...

The whole point of Keep It Simple, Stupid is that many people who design and implement new things are in the bright to genius category, including very bright somewhere in between. It's a matter of pride and skill to be able to make things very complicated and still understand them. However, there are a several reasons not to make things complicated.

1. Complicated things are harder for an outsider to understand and fix later.
2. Complicated things are generally less robust and break easier.
3. People working with complicated things tend to lose sight of the original intended purpose of that item, and all kinds of bells and whistles get added at the expense of the main functions.
4. No matter how smart you are, the jobs of programmer, engineer, essayist, cabinet maker, et cetera are more or less about managing complexity in the first place. At some point of introducing additional complexity, even the smartest people can't hold enough of a project in their heads at once. Paragraphs, chapters, subroutines, modules, reusable parts, and templates (both the material working and programming kinds) are tools to help localize complexity -- that is, they raise the complexity a manageable amount in several places so the overal complexity can be reduced.

Almost anyone can screw together premade cabinets that have been disassembled if they have the directions and enough patience. It's the cabinet maker who takes a bunch of lumber, planes the cabinets, makes the right cuts, puts the wood on the router table with the right jigs, and sands the rough spots out. This is managing complexity by taking a bunch of raw materials and making parts that connect, then conencting the parts. Having premade screws in a package and glue in a bottle of course are helpful. We as programmers are lucky that often many of our parts are already made.

Almost anyone, likewise, can figure out a Hello World program if given a reference manual on a language. Fewer people can reason about a 100-line program with no formal flow control. Even fewer can reason about a 1000-line program with no formal flow control. Most people can understand a program with ten subroutines doing ten well-defined things each ten lines long. If those ten each call ten more well-defined subs, that's not much of a stretch either. Three 40-line subroutines of course can be as reasonable as ten ten-line ones, depending on the problem you're trying to solve. Loops, subroutines, modules, blocks, and a certain level of syntactic sugar are all helpful precisely because they let one focus on the steps to solve a problem at one moment and how to break down an individual step into substeps at another time.

There are of course many other tools to help make things less complex, but the best tool to manage complexity is a well-trained and/or insightful mind. Knowing where you can eliminate complexity and where it's safe to have a little more than usual takes training, practice, or a really good eye -- preferably all three.

It's probably the art and science of managing complexity that accounts for most of the huge differences among lines of working code per day produced by programmers using the same language. These differences are not usually measured in numbers of individual lines, but in multiples or even orders of magnitude.