All I Really Need to Know About Programming I Learned From Fairy Tales

Software development methodologies are designed to help us produce cleaner, better and more maintainable code. Books and journals are produced at a staggering rate, filled with the latest answers to all our coding and maintenance woes. As programmers we are all by now expected to be hyper-productive and error-free.

The names change, but the ideologies remain similar. Beck and Fowler may have displaced Weinberg and Constantine, who in turn displaced Knuth and Kernighan, but these are all mere pretenders. As Isaac Newton said, albeit in sarcasm, we all stand on the shoulders of giants. In order to see where all this wisdom originated, we must travel back further still - back to the tales we were told as children, the stories we heard at our mother's knee. We need to rediscover the truths that are in our folklore.

I believe the time is ripe for significantly better documentation of programs [where the programmer] chooses the names of variables carefully and explains what each variable means. - Donald Knuth

A fine sentiment from the ever-wise Knuth. Of course, it is common sense to name your variables wisely. It adds an extra layer of meaning to your code, which can greatly ease future maintenance. But doesn't that sound like a familiar lesson? Where did we first come across the power of naming? Rumplestilskin, of course. Think back to the difficulties the Queen faced in puzzling out the naming convention there!

Or consider the interface to a software library. This is notoriously hard to get right, and the price of getting it wrong is even higher than badly named variables. So software developers learn about the principle of encapsulation. Rather than displaying the innards for all to see, we should hide away all the workings, providing a clean and usable front end. This is, of course, a great piece of advice. But again it is neither new, nor original. In fact, this information has been around for a very long time. Consider the tale of Hansel and Gretel. If the children had have been able to see the cauldrons, potions, jail cells and oven hidden the witch's house, they would never have gone near it.

But instead, the witch encapsulated all the horrible things, and put all the things that children like on display. (Of course, the witch had a bug in her system, which allowed the children to escape, but that is a different matter entirely!)

Even the issues involved choosing a software library were implanted when we were youngsters. I spend most of my time programming in Perl, which has one of the largest public resources of any language: the Comprehensive Perl Archive Network
(CPAN). One of the benefits of these sorts of libraries is that any problem you are trying to solve may already have been solved by someone before you who has released their code for free use. In fact this has probably happened more than once, in many different ways. So it is always good to choose amongst these libraries carefully, in order to find the one that will solve your own particular problem, in the best manner. Of course we learnt this in our youth from Goldilocks. She didn't like the big bowl of porridge, so she tried the middle sized one, which still wasn't to her liking, but the littlest one was exactly what she was looking for. (Of course, there are lessons to be learnt in this story about hacking and computer misuse, but that's for another day!)

Or consider testing. The recent rise of the agile methodologies, such as XP, have re-awakened developers to the power of testing. A good test suite, with full regression tests, can save a project. In fact, some go as far as to recommend you write your tests before you write any code.

But again this is hardly a new concept. Remember Chicken Licken? Unable to correctly identify a problem, he believed his entire system was failing, and led his entire project to disaster. With only had a simple test suite he could have been much more confident in his environment, and quickly recognised the problem solely as untested external input.

I could go on and on. There are many other tales which also show that far from being a new science, Computer Science has just tapped into our universal stories and dressed them up with new terminologies. But hopefully this small taster demonstrates that there may be alternative sources when you're looking for further information on a new concept you've discovered in your favourite buzzword-compliant journal.