|The stupid question is the question not asked|
Comment onby gods
|on Feb 11, 2000 at 00:06 UTC||Need Help??|
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.
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.
Christopher E. Stith