"Code Monkeys" and the "Software Eunuchs"

Its odd given the historical roots of programming - and in many ways its growing complexity -that the term 'Code Monkey' should have arisen.

You don't get 'Lawyer Monkeys' or 'Financial Monkeys', so why has this derogatory term emerged? 

My view is that this is the result of a 'devaluation' of the role of programmers and the increased demarcation of roles that has arisen - at least in part - from the introduction of the Waterfall methodology.

The demeaning term of "Code Monkey"  suggests that coding is just a basic and simple process of churning out lines of code according to the specification. Rather like a copy typist or a translator taking a specification and transposing it onto the computer. The "real brains" being with the analyst, the designer or the architect (in fact anyone but the person who built it). No wonder many coders want to become something other than a coder because they don't feel their role is valued. 

It may seem a rather minor point to be making, but actually I believe this has contributed significantly to poor software. Naturally it is demoralising to programmers to be thought of as "Code Monkeys" (either explicitly or implicitly), but more than this, it disengages and divorces them from the analysis, the design, the user, in fact everything except the lines of codes they are "cutting" (not sure I like that expression either).

From a coders perspective, they feel more like a "Software eunuch", a coder without involvement, influence or power over their project. 

So product development is reduced from being a creative team effort to a production line effort ('A' doing what 'B' passed down the line) and unidirectional.

This is where you get the typical "swing" characterised so well in the cartoon.

You can just hear the programmer turn round saying "but I'm just the code monkey" not as a badge of honour, but to excuse their involvement in a project they had no influence. 

There are many lessons to take way from these experiences, one of which is the need for team work and joint ownership of outcomes not simply isolated ownership of processes or individual deliverables that might be expected in a production line environment.

The other is the recognition that coding is an intellegent and creative activity not best suited to monkeys of any description, and that intelligent creative people have more to contribute to the development process than simply cutting code.  

This is one reason why I believe the Agile methodology has made a significant positive impact on development due to its much higher involvement and engagement with developers. Certainly this is my experience.  

My Three  (R)evolution Rules...

1) Don't hire code monkeys.

2) Don't treat coders like monkeys and

(coders)

3) Don't work like code monkeys.

p.s. they never did get any monkeys to type the works  - or even words - of Shakespeare.

The Three Legged Dog

One of my bug bears - and everyone in IT seems to have at least one – is performance.

Badly performing applications and operating systems really annoy me – often more than other bugs due to their persistence - and more importantly, reduce my productivity. Yet such an annoying feature seems commonplace and I for one do not buy the “it’s the hardware” argument any more than I would buy the “it’s the road” argument for a badly performing car.

I should distinguish between apps run on recommended hardware and those run on an old desktop next to the broom cupboard in an office – far far away... - a not too uncommon experience.

I am sure many of us can catalogue the list of applications and operating systems that fail to perform everyday functions. I have previously referred to Vista as poorly performing (and in my view too fat to live) and even my brand new HTC PDA - sporting Windows Mobile 6.1 – runs like a snail.

As well as not buying into the “it would work well on a CRAY supercomputer”, I also don’t buy into the “part of testing” argument either. Sure, testing should report the issue and indeed FAIL the release because of it, but they are hardly responsible for the performance(though I have to question why they do not exercise this veto more often).

Finally I do not buy into the “it’s a bug” argument. Sure, it is a bug, but not in the sense that I find performance normally referred to. E.g. that that performance issues will become apparent during Performance Testing which, according the V-MODEL, occurs during system testing.

Of course, this is a reasonable place for verification BUT not the first instant for this testing, in the same way that you would not expect it to be the first place to discover of bugs that would otherwise be discovered during unit testing.

I also do not subscribe to the idea that code performs by default and it is only the random occurance of bugs that interfere with this natural state of affairs. I assert that actually the reverse is true; that unless performance is architected and coded in from the start, then it will always perform badly. I would also assert that this statement is more able to explain the reality of our experience of applications.

In my experience, more often than not, the functionality has had to be re-written from scratch – rather than bug fixed - due to its poor performance. It has not been a “bug that crept in” but simply the absence of performance architected/designed code. This also explains why poor performance often isn’t rectified pre-release due to the cost of re-writing code and the effect on the date of release.

However, this is all the more reason why code needs to be architected and designed for performance and not just functionality. It would appear that “non functional requirements” - such as performance – are treated as “soft” requirements rather than “hard” requirements, the implication being that they are an optional extras.

I do not buy into this or the run out of time argument either, since this performance has to be considered up front, not last. If you leave it to last you have left it too late.

The example I had quoted to me on several occasions is the cash machine. Accepting all the functionality of the cash machine, if it took 10-15 minutes to dispense the cash, just how often would you use it?

I also understand that performance (and also scalability) is harder to achieve these days due to “The Stack”. In the “good ‘ole days” you coded in machine code/assembler direct to the CPU. Now you go through numerous stacks, api’s, classes etc which you didn’t write and have actually no idea how they perform under different circumstances. But that only sustains my previous assertion that code does not perform by default, but only through careful design, architecture and unit testing.

It is also true that code may have different performance profiles given the tasks required. For instance, a piece of code relating to train schedules may be very quick to list all the trains departing on a given day, but horrendously slow to list the trains on a given line. This dimensional performance characteristic can be present in many different areas.

Another mistake is data processing; Developers responsible for data entry logic can overly influence the schema for data entry performance over data access, yet data reads often account for 80% of db access in the wild. Thus data entry is fast (since it is dictated initially) but data access is slow. The effect is poor performance overall.

So my TEN principles for improving performance are;

1. Use cases must include performance profiles/response times.
2. Design must include reporting, scope and response times.
3. DBA must be involved in database design and focus on data access/reporting performance.
4. Architecture must be involved in development start-up meetings with performance a key agenda item.
5. Developers need regular performance training.
6. Unit Testing MUST include performance profiling including use cases which effect data dimensions/reporting etc.
7. Developers/architects need to include performance strategies as part of their training/coding approach.
8. Unit Testing must have success/failure criteria including performance.
9. Architecture must be involved in reviewing code not just in terms of formation/patterns/quality but also performance
10. QA Departments are given veto over poor performing releases.