Now I know better than to rise to deliberately inflamatory comments, but Tim Bryce seems to be deadly serious when he espouses his ‘Theory P’. I’m going to try to respond to this article in as level-headed a fashion as I can. Let’s go.

(Yes I know it’s from 2005, but I only just read it and I assume Bryce’s attitude won’t have changed much.)

The concept of Theory P does not attempt to introduce any new theories of management. Instead, it identifies those elements from Theories “X”, “Y” and “Z” pertaining directly to the management of Programmers, hence the Theory “P” designation. Theory P, therefore, represents a style of management for a particular job segment.

The fact that he’s touting this as a ‘theory’, rather than just some opinions of his, makes it hard to take seriously. He’s already being condescending by dressing up his well-intentioned management advice as something loftier than it is.

In many cases, management is faced with a paradox: how to manage the programming department without irritating the programmers and cause them to abandon the company, leaving corporate systems prone to malfunction and in need of maintenance. Programmers are hip to this and often use this as leverage for job security.

This is not a paradox, it’s a dilemma. And in any case, why does he view managing people (yes, programmers are people, too) as inherently confrontational? Chances are, if your priority as a manager is avoiding antagonising your workforce, you’re in the wrong job. Bryce seems downright scared of us.

The more effectively we manage the people who program the computer, the better we can utilize the systems to support the information needs of the business.

Who talks like this? If he’s willing to concede that programmers are human, then I’ll do likewise. Does he talk like this to his kids? He later accuses programmers of using protracted language to show off. I’ll say no more.

First, I deliberately avoided the term “Software Engineer” because this would imply the use of a scientific method to programming. Regardless of how one feels about the profession, this is hardly the case. Basically, the programmer’s task is to convert human understandable specifications into machine understandable instructions. From this perspective, a programmer can best be characterized as a translator. Unfortunately, such a delineation chafes people in this profession.

I agree to some extent that programming is not scientific, although I feel he doesn’t want to call us Engineers because it makes us sound important. He prefers Programmers, to rhyme with Worker Bees. The reality is that programming requires the ability to understand at least basic maths and have a highly logical mind. You don’t need to be genius, but these are traits associated with science. The fact that something is not straightforward does not make it unscientific. Programming works by you coming up with an idea for a solution to a problem, testing it to see if it works, then trying something else if it doesn’t. Sounds an awful lot like the scientific method, even if the details are a tad haphazard.

He is right to note that “such a delineation chafes people in this profession”. I should say it chafes translators, too. Try telling an accomplished literary translator that they are ‘just’ a translator and see how it goes down. His suggestion is that programming is just typing successive instructions into a machine. It might have been like that when he started out, but not any more.

Programmers tend to perceive themselves as free-spirited intellectuals who possess the magic of technology. … To outsiders, programmers are viewed as a sort of inner-circle of magicians who speak a rather cryptic language aimed at impressing others, as well as themselves. Such verbosity may actually mask some serious character flaws in their personality.

Every field of human activity has some sort of jargon associated with it. You could argue that language is itself a form of jargon designed for describing concepts that most people are familiar with. I can’t help how programmers are viewed to “outsiders” (he often asserts that we deliberately shun non-techies) but I can tell you that often, programmers need to discuss concepts that have no real-world analogues. You wouldn’t ask a particle physicist to refer to the W+ boson in terms of something ‘everyday’. We have strange names for things because they don’t exist anywhere except inside computers and we need a common language with which to discuss them. And I don’t feel I need to bother answering his suggestion that we tend to have “serious character flaws”.

It is not unusual for programmers to have problems socializing with others outside of their profession. Their language and technical interests tend to make them somewhat cliquish

Again, this could apply to any realm of human interest. People with common interests flock together because it makes them feel all warm and fuzzy. Some techies aren’t the most socially adept people, but I feel he’s appealing to the cartoon stereotype of spotty nerds hacking away in their bedrooms a bit too much.

There are few, if any, true programming geniuses in the average corporate shop.

That’s why we call them average. I don’t find it surprising that the leaders of the field aren’t working in the same office as me. I do find it surprising that Tim Bryce thinks that not being a genius makes one worthy of contempt.

Regardless of the image they wish to project, the average programmer does not have a higher IQ than any other worker with a college degree. In fact, they may even be lower. Most exhibit little imagination and require considerable instruction and coaching in performing their job. When they have mastered a particular programming task, the source code becomes a part of their portfolio which they carry from one job to the next. So much so, that copying or stealing source code is actually the predominant mode of development in most companies. Consequently, there is little original source code being produced in today’s software.

Hold up, what?

… copying or stealing source code is actually the predominant mode of development in most companies.

Sorry, thought I read that wrong. For someone who claims to have 30 years of industry experience not to understand the concept of library code, frameworks etc is unbelievable. Also, if no original source code is being written, what am I spending day after day doing? You think Rails magically understands the requirements of my company’s new online venture and writes it all for me? However low-level your source code is, there is still some sort of framework between you and the machine. I don’t see anything wrong with using ActiveRecord to handle my database for me, in the same way that I don’t think I’m cheating by not pushing individual electrons around or writing my whole web app using assembly language. Pushing electrons around is a solved problem, which my motherboard handles very nicely, thank you.

It is now too convenient for an employee to walk away with source code a company paid dearly for.

As far as I’m aware, I’m not paid by the number of original lines of code I produce, I’m paid to deliver working software. My future employers will no doubt be pleased if they present me with a problem that I already coded a solution to on a previous job. I doubt my boss would think it a good use of company time for me to implement my own ORM from scratch when a perfectly serviceable and extensible one already exists. Bryce wants to make a good business case for managing programmers, so how come he wants us to spend weeks and months reinventing the wheel on each new project?

Edit I didn’t know this at the time, but code you write while at work is actually the property of your employer. I maintain that, despite this, there is a dividing line to be drawn somewhere over what for want of a better term I’m going to refer to as ‘fair use’. I think anything one might reasonably refer to as a ‘snippet’ of code for some very generic task is fair game for throwing in your pastebin. We programmers learn partly by sharing such snippets on mailing lists. Obviously I would never share anything substantive or business-specific with the public unless my employer were open-sourcing the product, and I think that managers who would assume otherwise of their staff are doing themselves no favours.

If programmers do not demonstrate personal initiative to learn new subjects, the company should not waste time and money trying to teach them

I actually agree with him here: unwillingness to learn is the sole reason why the web is full of bloated <table>-based pages and reams of inline, everything-is-global JavaScript. He states before this that programmers “usually possess a curiosity about technological developments”, but then contradicts himself by saying we need poking now and again to force us to learn new things. In my mind, if you’re in this industry and haven’t learned anything new in the last, say, month, then there’s something amiss. I don’t care how tiny it is. You learned about a method in your chosen framework that you didn’t know about before. If you can’t do that you shouldn’t be programming.

It is well known that programmers generally abhor organization and discipline. Their desks are often littered with stacks of paper and other debris. … In fact, many programmers deliberately appear disorganized to make it difficult to judge how they are progressing on their work effort and reveal inadequacies in workmanship.

We are, to a man, disorganised lazy lying scum. We spend all day on Facebook or MySpace and never do any work. And you were concerned about making us leave your company. You don’t need us, man, we’ll just mess up the place and hog network bandwidth by downloading music from BitTorrent. That’s right, we’re thieves too. That’s why we steal so much of your source code. Seriously though, if you want to know how my work’s progressing, ask me. Chances are, I’ll tell you, because I don’t like the idea that you think I’m not doing any work, and why would I withhold information from you about the software you’re paying me to write? Bryce’s philosophy seems to be based on the idea that everyone will lie to him all the time, which in all likelihood is a self-fulfilling prophecy.

Mental laziness can also be found in planning and documenting software. Instead of carefully thinking through the logic of a program using graphics and text, most programmers prefer to dive into source code without much thinking

To be sure, some planning is good. It helps to have some grasp of what the finished product should do before you begin work. But, writing software is what Horst Rittel and Melvin Webber would call a wicked problem: it can be “clearly defined only by solving it, or by solving part of it”. You will probably rewrite your first attempt at coding something, but that’s okay. You won’t fully understand what you’re writing until after you’ve begun writing it.

Improve communications within the programming staff by developing a standard glossary of terms. This will also be useful to outsiders who have to interface with programmers.

A standard glossary of terms? If you need standard terms for development issues that aren’t already in everyone’s vocabulary, chances are there’s some computer science jargon (heaven forfend) for whatver it is you’re trying to discuss. How’s about we stick to that, and then we only have one group of people who need to learn some new words. I know this sounds lazy, but if you ask developers to learn some arbitrary set of new words just to talk to you I guarantee you won’t get a straight answer out of them. Also, I know I’m only young but never in my life have I thought of myself as “interfacing” with another human being.

Develop security measures to safeguard the company’s intellectual property.

Again, DO NOT stop me reusing library code. It keeps me productive and therefore keeps you happy. Of course I’m not going to hand over specific implementation code for your e-commerce credit card handling system. Give me a bit of respect. Also, I know you paid for it, but code I write is my intellectual property – I created it, the copyright is mine. If it were yours, well then you wouldn’t need me to write it for you. I’ve since discovered this to be factually incorrect (see ‘Edit’ above).

He rounds up with a series of vague well-meaning statements that could easily apply to anyone in any industry. Most people think their jobs are hard and underpaid. Programmers are no more whiny than the rest of society. He really strikes gold in the comments though:

In my +30 years of experience in this field, you are the first to accuse me of inproprieties and there appears to be no reasoning with you over this. Your arguments give proof that:

1. I have forgotten more about development than you are ever going to know.

2. My thesis regarding Theory P is correct.

All the Best,
Tim Bryce

There probably aren’t many really good ways of asserting one’s authority on a subject, but he’s scraping the barrel with this. How’s about, “With respect, I’ve been in this industry for 30 years and this has been my general experience. If you don’t fit this mold then that’s great, I’m glad to hear you’re not one of the people I’m talking about.” Also, for the record: disagreement does not prove your ‘thesis’.

I tried. I mean, I really tried to be level headed about this. My concern is that if managers generally have this attitude, not just to programmers, but to staff in general, they shouldn’t be surprised that they need to be defensive all the time. We, the programmers, do not hate you. We like getting paid to do stuff we’d happily occupy our free time doing, as long as you’ve an interesting project for us to work on. Stop running your business like all your staff are out to rob you, and please please please: do something with your website. If the developers that cooked that thing up are representative of the programmers he’s met over the years, I’m not surprised he doesn’t trust us.