Are you a Code Monkey?

... or are you an Organ Grinder?

By Tony Marston

17th March 2006

The title of this document refers to a street entertainer, once common but now rare, known as a Hurdy Gurdy man or Organ Grinder. He used to travel around with a hand-operated organ, or hurdy gurdy, playing tunes for anybody who would listen, and hope that his grateful audience would drop a coin or two into his tin cup. As entertainment he would usually have a pet monkey, often dressed in a cute little costume, who would dance for the audience and sometimes perform simple tricks, like doffing his cute little cap, or "playing dead for the Queen".

The organ grinder was the man in charge. He turned the handle to grind out a tune, and all the monkey had to do was dance to that tune. The monkey could not make a move without the consent of his master.

This relationship between man and monkey led an irate customer, when confronted by a lowly underling when he wanted to speak directly to the man in change, to utter that immortal phrase: "I want to speak to the organ grinder, not his monkey".

In the world of software development, just like many other areas of human endeavour, there are people with real talent who are at the top of their profession, up there with the organ grinders, while there are a great number who are stuck on the bottom rung of the ladder down there with the monkeys.

Which one are you? An "organ grinder" who calls the tune, or a "monkey" who can do nothing but dance to somebody else's tune? Are you a "top dog" or a "bottom feeder"?

Here are some clues to look out for:

1. A monkey knows only what he has been taught, not what he has learned.

Teaching is when knowledge is passed from one person to another while learning is what a person does on his/her own. Learning is what comes from personal experience, not the second-hand experience of others. Learning comes from trial and error, from making mistakes. Although there may be some cases where the documented experiences of others may prevent you from repeating tragic or costly mistakes, in a lot of instances it is nothing more than "this is the way that *I* do it, so this is the way that *you* should do it". A monkey will follow what he is taught to the letter and without question.

An organ grinder, on the other hand, will not take everything at face value. He will take the time to explore other possibilities and compare their individual advantages and disadvantages. He will want to discover if other, and perhaps better methods exist. He may sometimes find that a particular method was rejected not because of a fault in that method, but because the critic's implementation of that method was faulty.

2. A monkey is incapable of original thought, he can only echo the thoughts of others.

Original thought means putting aside of set of ideas of others and trying something new for a change. Without trying something new it will not be possible to find something that may be better. A monkey is incapable of original thought, or perhaps is afraid of expressing that thought for fear of being mocked by his peers.

An organ grinder, on the other hand, has confidence in his own abilities. He is willing to try out new ideas, new methods, and if they produce better results he will not be afraid to stand up and say so. He may be mocked by those who refuse to listen, but he also knows that, sooner or later, the fact that his results are superior will be recognised by those with open minds.

3. A monkey can only imitate, never innovate.

Those who imitate others are followers, while those who are imitated are leaders. Progress cannot be made by hordes of imitators and followers, all they can do is maintain the status quo. Progress requires an original thought, a change in direction, a different approach, someone who can compose a new tune instead of constantly grinding out the old tune.

A monkey can only imitate, play "follow my leader", and will never be able to make improvements, to make progress. An organ grinder, on the other hand, will stand up and say "This may be the best that you can do, but it is not the best that I can do".

4. A monkey does not know when to break the rules.

Rules are drawn up by one individual or group to cover the circumstances encountered by that individual or group. But what if a new set of circumstances arises, one not encountered by the original rule makers? A monkey will try to bend the existing rules, or to offer different interpretations of those rules, in order to fit the new circumstances, with often less than optimum results.

An organ grinder, on the other hand, will recognise that the new situation cannot be covered by any existing rules so he will use his experience, his intelligence, to explore the new situation to see what new rules, if any, are needed.

5. A monkey is rules oriented, not results oriented.

A monkey will follow a set of rules blindly and without question, and assume that whatever is produced must be acceptable. He will not be able to tell whether the results are good or bad, just that the rules were followed. He is the kind of person who says "the operation was a success, but the patient died".

An organ grinder, on the other hand, will see that the results are not as good as they should be and seek out the reason why. He will seek out the places where the rules were applied incorrectly, or the wrong rules were applied, or where new rules should have been created. He will then take whatever action is necessary, including the making and breaking of rules, until the results are acceptable.

6. A monkey sees anything "different" as automatically "wrong".

A monkey is used to doing things in a particular way, in the way that he has been taught, and is resistant to change. As soon as he sees something different he will immediately pounce on the difference and proclaim "That is not the way that was taught to me by my masters, therefore it must be wrong". He will not even bother to examine the results, to see if they are an improvement or not. Rules are rules, the results are irrelevant.

An organ grinder, on the other hand, will see the different result and want to know how it was achieved. He will want to see how this new method actually works, to see if it can be incorporated into his own work so that he may produce a better result.

A wiser monkey may say "I didn't know that it could be done that way", in which case you have just identified a deficiency on the part of his master, an area where your knowledge and experience are obviously greater than his.

7. A monkey likes to perpetuate bad ideas "to be consistent".

A monkey does not have what it takes to recognise that a particular method or a particular rule is a hindrance rather than a help. His motto is "I've always done it this way" or perhaps "This is the only way I know". When moving to a new language or a new paradigm a monkey will want to carry forward as much of this old baggage as possible. He will not recognise that what worked in the old language is totally inappropriate in the new. He will not recognise that the new language has a different way of doing things and consequently a different set of rules apply.

An organ grinder, on the other hand, will recognise a new language for what it is - new and different. He will seek out the differences, the different ways, the different rules, and adapt himself accordingly. He will recognise that an old rule is now inappropriate, a hindrance instead of a help, and discard it without a second thought.

8. A monkey can only follow rules, he cannot make them.

Take a code monkey and promote him to project leader, then ask him to produce a set of development standards for the entire project. Watch him flounder like a fish out of water. I have seen development standards produced by such people, and they have got nothing at all to do with "best practice", just "the best that I can do (which is not much)" practice. Their idea of everyone working to the same standard is "this is the way that I do it, so if everyone does the same that will be good enough". All the programs were consistent, sure enough, but consistently low quality. Their rules are full of "do this" and "don't do that" without any word of explanation or justification.

An organ grinder, on the hand, knows the difference between "good practice" and "bad practice", and can explain why something should or should not be used. He can explain why the quick solution sometimes is prone to errors while the long solution is better because it avoids the same potential for errors. Not only does he know why a rule exists, he also knows when a rule is inappropriate or ineffective because of a change in circumstances.

9. A monkey cannot write reusable code.

To a monkey the only way to create reusable code is by the old copy and paste method, which results in copies of the same code being pasted in numerous places throughout the application. This also means that any bugs are also duplicated, and any bug fixes have to be duplicated in every single copy. Even if such a person can see where code is being duplicated they don't know how to extract it and put it in a reusable library, or they can't be bothered to make the effort.

An organ grinder, on the other hand, can spot instantly where a piece of code has been duplicated, and knows how to add that code to a reusable library. He also knows that any time spent in creating and testing a new library function is an investment that will reap rewards in the future.

10. A monkey cannot build an entire framework.

If a code monkey cannot produce coherent and effective development standards, or cannot produce libraries of reusable code, just watch him try and produce an entire development framework. He will try to start with a set of rules, then write code that conforms to those rules. If the rules are poor quality, or his understanding of those rules is faulty, then his implementation of those rules will be enough to make a grown man cry, or a saint swear. Just watch what happens when a code monkey tries to use as many design patterns as possible, but doesn't know how to use them effectively or appropriately. You may think that it's impossible to write spaghetti code using OO techniques, but a real code monkey will astound you with his culinary expertise.

An organ grinder, on the other hand, knows what results are expected and knows the best way to produce those results. He knows what design patterns to use, when to use them and how to use them. He will know the shortcomings of other frameworks and seek to eliminate them. He will know what rules to accept, and more importantly, what rules to reject. When exposed to the results of a real artisan, a code monkey is often heard to explain "I didn't know you could that!"

That's the difference between an organ grinder and a monkey - one knows, the other knows nothing.

Examples of code monkeys

Many years ago I heard one programmer complain that "COBOL is not a structured language". What the poor little mite had failed to realise is that COBOL does not force you to use a particular structure, neither does it prevent you from using a structure of your choice. This chump did not investigate the options that were available and choose the ones that suited him, instead he expected the language to do all his thinking for him.

As a junior programmer on a new project I was given a copy of the development standards created by the newly-promoted project leader. He was obviously out of his league as virtually everything he had written totally contradicted the standards I had encountered on previous projects. I struggled to conform to these standards, but found it very difficult to produce an acceptable result in an acceptable time frame. In the end I just threw his standards in the rubbish bin and wrote the program my way. A few weeks later my program was scrutinised by another more senior consultant in a project audit. His comment on my work was "This program is not written to the project standards, but it is the most well written and well documented program I have ever seen". If standards are supposed to represent "best practice" then how is it possible to totally ignore those standards and produce something which is recognisably better?

I was head hunted for a new project that was being developed in the 3 tier architecture, but the people in charge of the project knew less about the language than I did, and none of them had actually designed and built an entire framework, as I had. All they knew was what they had read about in books, about the "correct" way to design systems, the "correct" design patterns to use, and so on. They had a team of six "experts" spend six months designing and building this wonderful new framework, then gave it to the developers to build the first two screens, one to enter search criteria and a second to read the database and display the records which matched that criteria. It took two developers two weeks to get those two simple screens to work. After a bit of fine tuning they managed to reduce it to only a single developer for two weeks. I told them their framework was rubbish, but they refused to listen. The client saw how long it would take to write the entire system and how much it would cost and told them to think again. They panicked. I demonstrated my own 2 tier framework in which I built the same two screens in 20 minutes instead of 10 days. The client was impressed, but the project architects rejected it because it was 2 tier and not 3 tier. So I converted my framework to 3 tier and built not just a search screen and a list screen, but also a insert, update, enquire and delete screen as well. This whole exercise took just two weeks. The project architects rejected it because I wasn't using the right design patterns. So I had managed to achieve in two weeks what they had failed to achieve in three man-years, yet they had the nerve to tell me that my methods were wrong!

There are rumours that one of the "enhancements" in PHP 6 will be that all function names and method names will become case sensitive for no good reason other than to be "consistent" with other languages. What these simians fail to realise is that other language may have the ability to hide their case sensitivity by auto-correcting the case of any variable or function names as they are keyed in, thus making it impossible to make a mistake. PHP does not have this capability as (a) it s not a compiled language, and (b) it does not have an IDE with this capability. As far as I am concerned any language which allows you to use the same function name or variable name with the same spelling but different case to mean totally different things is a BAD language. Can you name me any language which supplies the same function name in different mixtures of case to mean different things? You can't! Then take a guess as to why not. BECAUSE IT IS NOT A GOOD IDEA, YOU CHUMP!

There are some poor deluded souls who proclaim that it is not possible to write object oriented code with PHP. This is absolute rubbish. All that a language requires to offer in order to say that it supports object oriented programming is the following:

Everything else, as far as I am concerned, is secondary and entirely optional. There are some add-on features in other languages which are entirely irrelevant in PHP simply because of deficiencies in those other languages which do not exist in PHP. Interfaces are a prime example. Other languages may need them because of how they deal with optional arguments, or arguments of different types, but PHP has its own method of dealing with these which makes interfaces a waste of time.

Instead of saying that PHP does not support OOP perhaps what they really mean is that PHP does not support their style of OOP. If this is the case then I would argue that it is their style which is questionable.

There is another set of poor deluded souls who insist that my framework does not achieve the correct separation of responsibilities because I have business logic, data access logic and presentation layer logic in the same class. These chumps do not understand the difference between "information" and "logic". Information is "data" while logic is "the processing of that data". Take the following examples:

Each business object contains information on the structure of the database table to which it relates, but this information is not processed until it is passed to the data access object. It is the data access object, and ONLY the data access object, which constructs complete SQL queries and sends them to the database via the relevant API.

Each business object contains information on what HTML control is to be used when each field is added to an HTML form, but this information is not processed until it is passed to the presentation layer. It is the presentation layer, and ONLY the presentation layer, which constructs any HTML output which s returned to the client's browser.

There is another group of confused individuals who will insist that encapsulation means "information hiding". NO IT DOESN'T! If you chumps bother to read the manuals carefully you will see that encapsulation is about hiding the implementation (the code which processes the data) and not about hiding information (the data which is processed by the code). I know the words have similar spellings, but they actually mean completely different things.

There are one or two OO purists out there who think that I should be burned at the stake for committing the ultimate heresy - the breaking of their precious rules. Take for example my practice of creating a separate class for each database table. According to the purists this is totally wrong! Why? Because they have been taught that it is wrong. Luckily I wasn't taught such stupidity, so I followed my instincts and wrote code which works. My logic is as follows:

A class is a blueprint for one or more instances. Is not a table schema a blueprint for one or more instances (records)?

Each object which has a different blueprint requires a different class. As the structure and business rules of the CUSTOMER table are totally different to that of the PRODUCT table, then it follows that they should have different classes.

To cover the fact that there is quite a lot of processing which is common to all database tables I created an abstract class to contain all this common processing. Individual database tables then extend this superclass into separate subclasses, one per table. Each subclass contains the specific implementation details for one database table.

When these purists tell me that my methods are wrong they are making a fundamental mistake - my methods cannot be wrong for the simple reason that they work. My methods may be different, but since when has being different been a crime?

When designing a relational database there may be times when a semantic primary key is not a good idea, in which case a technical (or surrogate) key should be used instead. These are usually numerical values which are generated by some sort of database-managed sequence. While I agree that technical primary keys are a good idea in some circumstances I do not agree with the idea that they should be used in all circumstances (please refer to Technical Keys - Their Uses and Abuses for details). I especially dislike the idea that every primary key should be named 'ID'. To my mind there are two ways of using technical primary keys:

Intelligently

Indiscriminately

Those who choose option #2 are demonstrating that they do not have enough of option #1.

There are some programmers who insist that it is "clever" or "cool" to be able to write code using as few keystrokes as possible. They think that this qualifies as "efficient programming". What these poor dears fail to realise is that program code is written primarily to be read by humans and only incidentally to be executed by a computer. Programmers, especially maintenance programmers, spend more time reading code than they do writing it, therefore it is absolutely essential that it is readable. By this I mean that anybody other than the original author should be able to look at the code and understand what it does and how it does it so that they can fix it or enhance it without too much effort. Most of the people who look at a piece of code do not have the same experience as the author, so it is better to invest in a few more keystrokes up front so that a new reader can get to grips with the code as quickly as possible. It is a waste of time having some really clever code if no-one but the original author can maintain it.

I recently had an e-mail from someone who asked "How can you use foreign keys in your application without having any foreign key constraints in your database?" This shows a distinct hole in this person's education as he has obviously been taught that there is "only one way" to deal with foreign keys, and that is to delegate all processing to the database. If this is what young people are being taught today then I can say say is that our future is slowly being flushed down the toilet. Let me offer some enlightenment:

Foreign key constraints are optional, not mandatory.

Database triggers are optional, not mandatory.

Stored procedures are optional, not mandatory.

I do not need foreign key constraints to access tables within my application. I do not need foreign key constraints to construct an SQL query with a JOIN. I do not have to move logic out of my application and into the database. Because I do not have to do those things I am simply exercising the option not to do those things. I was taught to write applications with databases which did not have any of those "features", so I know how to write code which does not rely on them. This person obviously does not, yet he has the nerve to question my methods!

The evolution of "Company Policy"

Start with a cage containing five monkeys. In the cage, hang a banana on a string and put stairs under it. Before long, a monkey will go up the stairs and start to climb towards the banana. As soon as he touches the stairs, spray all the monkeys with cold water.

After a while, another monkey makes an attempt with the same result - all the monkeys are sprayed with cold water. Turn off the cold water.

If, later, another monkey tries to climb the stairs, the other monkeys will try to prevent it even though no water sprays them. Now, remove one monkey from the cage and replace it with a new one. The new monkey sees the banana and wants to climb the stairs. To his horror, all of the monkeys attack him. After another attempt and attack, he knows that if he tries to climb the stairs, he will be assaulted.

Next, remove another of the original five monkeys and replace it with a new one.

The newcomer goes to the stairs and is attacked. The previous newcomer takes part in the punishment with enthusiasm.

Again, replace a third original monkey with a new one. The new one makes it to the stairs and is attacked as well. Two of the four monkeys that beat him up have no idea why they were not permitted to climb the stairs, or why they are participating in the beating of the newest monkey.

After replacing the fourth and fifth original monkeys, all the monkeys which have been sprayed with cold water have been replaced. Nevertheless, no monkey ever again approaches the stairs.