It's Time to Play the Music (Muppet Show Part 1)

I'd like to point out that I'm not negative all the time. It's just that this entry might make it seem like it. I'm writing this now, while I'm still pissed off about it, and anyway, it's what you're supposed to do in a blog, isn't it? Moan, I mean. As m'colleague Shim would say, "People and/or things suck! Yay! Write a blog entry!" Or something like that. I can't do the accent. So. Anyway. There's a famous book in the field of software development, called Peopleware. It's probably not as famous as it should be, and it applies not just to software development/engineering, but to any endeavour where you're trying to get people to produce creative and high quality work, particularly what the authors term 'intellectual work'. One of the facts that Lister and DeMarco (the authors) present in this book is that the variation in productivity between software developers can vary by as much as a factor of 10. Those numbers can be a little confusing at first, so let's talk it out. In other words, if you take one of the best programmers and one of the worst, and give them the same task, the best guy* will finish ten times faster than the worst guy. So if the best guy finishes the task in a day, the worst guy will finish in in 10 days, or 2 freaking weeks as you and I would call it. And don't go thinking smugly to yourself "Ah, yes, but the guy who finishes in a day will have produced rushed and shoddy work." because apparently that's not true either. The fastest guy's work will usually also be superior to the slowest guy's work. Read the book if you want more details on this. Some people (myself included) often have a problem believing this statistic, even though the authors provide substantial proof from their own experiments and observations in the workplace. Well, I don't have that problem any more, because I recently worked with yet another muppet who drove home the truth of Lister and DeMarco's claims.

Quite simply, he sucks.

One of the opinions I have formed in my programming career is that one of the most important characteristics of a programmer is honesty. Programming is complicated enough without some ignorant fool trying to bullshit you that they know what they are talking about. If I ask a programmer on my team a question, and they don't know the answer, I expect the first thing they say to be "I don't know." I don't expect some load of regurgitated rubbish that they hope will make them look smart or salvage their ego.

Not a terribly good role model for programmers.

The problem with the Muppet (as I shall henceforth refer to him) was that he had the following characteristics:

• He thought he was an expert in his field.
• He so was not an expert in his field.
• He was fiercely proud (of what, I am not sure).
• He would never accept that he was wrong about anything.
• He had a deeply-ingrained simplistic view on just about every technical subject.
• He was rubbish.

You're probably thinking that this is a deadly combination, and you'd be right.

The Arena of Pain

The scenario under which I had to experience this super-star's talents was fairly simple - the implementation of a vertical web application. He was the implementer, and I was managing the project, i.e. him (and supposedly other projects, but in the end it took all my time to manage him, and to do the development work to pick up his shortfall in productivity).

The application was not that complicated. It involved processing orders, dispatching and maintaining stock levels, and so on. So not exactly rocket science.

Not actually that complicated.

The system used to implement the application was Zope. After having learned a fair amount about Zope on this project (I'd never used/encountered it before), I'll be frank and admit that I'm not its number 1 fan.

This was exacerbated by the fact that there are essentially two main ways of using Zope:

1. The old, stupid way: mixing the markup and logic/code in Zope's DTML files - a bit like classic ASP programming (as I understand it).
2. The new, recommended hotness: separating markup and logic, and using a language like Python to implement the logic in a clean way.

You'll never guess what the muppet's preferred method was.

CNSQNS

Of course, Einstein chose the old, stupid way. This was not from mere ignorance of the new, second way of doing things. Oh no. He had heard about the separation of presentation and logic, but wanted no truck with it. The old way was 'much better'. He kept referring to it as 'pure Zope'. I was pretty sure it was pure something, but that wasn't it.

Cards on the Table

Now, as the muppet had never worked with me before, and I was his manager, I guessed that he would assume I was some know-nothing PHB who wouldn't be able to help him materially in any way. Early indications confirmed this. When he found out that I had never used Zope, I could see in his eyes that he was mentally writing me off as a useless idiot. Which was ironic, really.

Anything You Can Do

The muppet said that even if I learned Zope, I wouldn't be able to help him with the development work for about a month. The fact that after 3 days I was writing DTML code that linked to complex SQL queries and generated sales reports web pages seemed to be an annoyance to him. In fact, he told me it was a waste of time, because the database schema wasn't finished yet, so I would have to 'rewrite it all' when he finalised the schema for storing orders. I tried to explain that I'd just have to adjust the SQL query to get the data from the relevant table/field, and possibly do some minor adjustments to data ordering, etc, but he wasn't having it.

I believed that the work I had done on the UI and generation of the report presentation was actually useful work, that would require minimal updates when the Muppet actually got his act together and decided what the database schema would be. Stunningly, this turned out to be true. In fact, the Muppet used to almost gleefully tell me in status meetings that he had changed the database schema again, and that I would have to 'rewrite' all my report code. In each case it rarely took me more than about 10 minutes to tweak the SQL query to cope with his changes.

In short, he didn't seem to have a clue about designing to cope with change. This became evident as whenever he had to change his schema, he seemed to have to rewrite a lot of his code. We'd hit a minor problem that needed a slight change to the database, and he'd say it would take 3 days to update his code. Initially I argued with this, but eventually I just sighed, because he actually did seem to be telling the truth - he really was that incompetent.

The Expert Speaks

Just to give you a little flavour of the muppet's expertise and quality of work - for a start, his code had no comments. I think I'm right in saying none, rather than 'not many'. This was just one of the many ways that his work spoke to me.

Another favourite was in his implementation of product orders. An order line consisted basically of a product code, and a quantity. The price also needed to be stored in the order line (so that if the price of a product changed, it wasn't retroactively applied to all previous orders referencing that product).

Imagine my joy when I examined the orders database table, and found the following named fields:

• price1
• price2
• price3
• price4
• price5
• price6

In case you're wondering, all the fields were used.

"That is not the preferred nomenclature."

The various fields were sundry nightmarish combinations of price x qty, price inc. VAT, price ex. VAT, and so on.

I can only thank God that he didn't name them as follows:

• priceeachexvat
• priceeachincvat
• totalpriceexvat
• totalpriceincvat
• eachvat
• totalvat

...otherwise, someone else (or, in fact, the original programmer) might have stood a chance of working out what the hell these fields were used for without first poring over the source code for two days.

Later, I renamed as many of these fields as I felt safe doing - but usually that meant using the 'as' operator in the SQL queries. I would have changed the field names in the schema itself, but they were used all over the place, and Zope's facility for search/replace is unbelievably laughable for DTML, and I didn't have the time to waste finding out if it would be worth it.

You probably won't be surprised to hear that I ditched the last two price fields - I managed to find a way of synthesising them when I needed those values from the other fields. See if you SQL gurus can work out how I managed that super-human feat of programming! Yes, that was sarcasm.

It's the Rebels, Sir. And they've got a flag.

Another stroke of genius was that almost every database table had a field called 'flag1'. Now, see if you can guess what this means.

I can wait.

Give up?

Well, 'flag1' was a boolean flag that marked a record as being active, or deleted, whichever way you look at it. Now, you might think that a field name like 'active' or 'deleted' might be more appropriate (and would indeed give you a clue as to the interpretation of literal flag values of 0 or 1), but you'd be a fool and a communist to think that.

To put your mind at ease, there were no instances of a 'flag2' field (or similarly named fields) anywhere in the schema.

Revision control? We don't need no steenkin' revision control!

A recurring theme of working with the muppet was that he would excitedly show me something that was part of the 'beauty of Zope', as he called it, and I would think "Isn't this just a poor implementation of <insert 20 year old programming technique>?"

"I haven't got time for this Mickey Mouse bullshit!"

Case in point: the marvellous Zope Undo feature!

Now, and brace yourself when I tell you this, because it's pretty damn exciting, but whenever you make an edit to a Zope script and store it in the database, then (I can hardly contain my awe), the Zope database keeps the old copy of the script!

Not only that. Not only that! You can go in and choose to 'undo' your changes to a script!

Veteran coders are at this point sitting on the floor, breathing hard, and wondering what hit them.

Anyway, it's possible that I spoiled the moment when I replied, after being shown this awesome feature, "So it's a form of revision control?"

And how right I was - it's a form of revision control. But sadly not a useful one.

You can't see diffs between two versions, or explore the history in a useful way, or look at change comments, etc. I know, I know - if he didn't even comment his code, why would he provide meta-documentation about it? I can dream, can't I?

And if you undo a change, then a 'redo' record (or some similar aberration) appears in the history, and after that I never could work out how to go backwards/forwards reliably in the history. Zope would usually tell me that some undo record or other could not be applied because some other undo record had not been applied yet. Or unapplied. Or re-applied. Or something. I found myself longing for Visual Sourcesafe.

I feel unusual

Right, that's enough vitriol for now. If you'll excuse me, I don't feel quite so. I'll continue documenting the madness in a future entry, including the exciting neologism 'Retrospec'!

I can hardly wait.

(Footnote: When I say 'guy', I am using it in a friendly, non-gender specific way. If it helps, you can imagine that when I say 'guy', I'm actually saying 'humanoid work-unit of unspecified gender'.)

« "I have in my hand a few simple leaves..." | Ph34r my syndication 5killz!!!11 »