Software Labourers


Problem: SoftwareEngineers are expensive. They're also cantankerous and intelligent and challenge management by generally being bright. You don't need engineers anyway, you don't need a Clifton suspension bridge, you just need this hole digging. Also hiring software engineers is time consuming and requires interviewing them and stuff.

Even if you hire skilled staff, they'll go and do skilled things and then you're trapped into hiring skilled people to look after it. And they keep leaving when you only offer them cost-of-living pay raises.

Context: Not only do you imagine SoftwareEngineers are completely interchangeable, you also imagine that they are interchangeable with any other job that involves, say, typing.

Solution: Rather than have a team of SoftwareEngineers, you have a team of labourers. Hire people who can write lots of code fast. In fact, just hire people and turn them into "software engineers". All it takes is a book on C++ and a desk. Maybe a course if you want them to be "senior software engineers".

Resulting Context: Tend to focus on making things "easy". Things like huge template files that just need a bit of search and replace on. Cute little shell scripts so no-one needs to understand any actual UNIX commands. Eg: rather than bother to lay out the directories properly and have everyone use "cd", you have projects dumped all over the place and a script called "workon" that has all the different project directories embedded in it by name, so you "don't need to know where they really are". That sort of thing. On having lots of procedures to follow rather than having the staff understand the logic behind things they just have to follow a checklist.

There's a plus-side in that the staff are imprisoned by their lack of knowledge: there's a barrier to exit effectively because they won't pass the technical interview to go work anywhere else. (Of course the chances that that place use anything as complicated as the techniques in their technical interview are pretty much nil; they'll have their own ways of making things "simpler".)

Nothing is documented properly. Because there's always a panic on (there always is in places like this) no-one ever documents all the "internal oddities" properly. Unfortunately, they've just created an environment where there are nothing BUT internal oddities...

Often, you find there's actually a software engineering god (or at least acolyte) hidden away somewhere - after all, someone's got to produce the "simple" interface to SQL for all the labourers to use. This is good in a way, because at least someone's organising things, but it makes the TruckNumber = 1 and puts a lot of stress on that one person.

Sometimes, and this is where it's scary, the software engineering god actually only just knows what he's doing. He's a GuruByAge? rather than by being a guru. This is the kind of place where they've gone out of their way to make the UNIX command lines look like DOS or other neat ideas. Typically use of Emacs will be banned because it's "insecure". {Have you ever noticed the number of companies that forbid the use of open source software because it's "insecure" but then have outlook as a standard mail client?)

Another source of the godhoodness is to hire in contractors. This is almost a sub-anti-pattern. You hire in contractors to do the complicated stuff so the staff "don't have to". The results are: tension between the (obviously) skilled contractors and the (obviously) unskilled staff: the contractors obviously get paid more, have the potential to earn more, aren't imprisoned by the barrier to exit. The staff try and make what they do more "complicated", often by obfuscating the information which makes it harder for the contractors to work. The contractors won't speak the internal language of the company and the company sure won't be speaking in DesignPatterns so there's an impedence mismatch. The contractors can't walk in and sit down and start work because they don't know the magic set of commands to type to get programs to compile. (It's usually not "make", and even if it is, it's usually not that simple: the project makefiles here rely on the project being in a certain place to be able to build: so I can't take a copy of the code to go play with because I can't build it anywhere other than where it's "supposed" to be built.)

And, and this is the crunch, sooner or later "you don't need a Clifton suspension bridge, you just need this hole digging" breaks down, when the hole stops being a simple hole and turns into an underground tunnel system to rival Hampton Court Maze.

Known uses: Roughly 50% of the companies I've worked with. Seriously. It's amazing how many people I've met who are now "software engineers" (and therefore seem to rank alongside me in the company's views) who a year ago were an accountant, a history graduate, studying for but not passing their A-levels, a furnature maker, an English teacher. Speaking as a software engineer who's made a great deal of investment in the career, I find it rather insulting that that person thinks it takes 3 years of degree plus a year of teacher training to become a teacher, but only a three week course on Java to become a software engineer...

Just imagine how you'd feel when that idiot job that only takes three weeks to learn pays twice as well as being a teacher.

I've also seen the pattern applied to:

Exceptions: It's not ALWAYS wrong to have people make a leap into development from something else. I know of several maths and physics graduates who've become excellent software engineers. It's just that you shouldn't assume it's an easy leap to make.

Moral: If you're trying to do complicated things, sooner or later you WILL need people who can think about complicated things or you won't do them.

Author: KatieLucas 14/11/02


Antimoral: Failure is usually an option. Project cancellation or failure to deliver will usually have zero effect on career if deftly managed. High costs or annoying employees may be worse. Hiring competent skilled people who may threaten your career may be fatal. People who can think about complicated things are often not needed or positively dislike by PointyHairedBosses.

I thought a previous employer was unique, but this is a surprisingly detailed description on how they worked. How common is this? The biggest difference was that the guru in this case was now absent, but in a way always present as a lingering cult of person.

I suppose its fair to say that on a team of, say, 30 people you're not going to need 30 Engineers. Perhaps one architect, 4 four engineers and 25 labourers. Nothing wrong with that, except that employers don't advertise for software labourers, they advertise for 'software engineers' to work in 'dynamic teams' with 'great prospects'. Then they wonder why intelligent people, given nothing to do for two years but dig (software) holes, down tools and leave. -- JayBell

With a team that size, I think you'd be better off firing at least 20 of the laborers. Let the remaining laborers pair with the skilled people, and soon you'll have a team that is much more productive and self-motivated than that 30-person team could ever be.

Unfortunately, your new skilled workforce will probably want more money, or may even leave to work somewhere else where they can put their new found skills to use. Of course, the solution to the thorny problem of keeping SoftwareLabourers in their place is DontTrainAnyone. -- JayBell

Ahh, but you now have 20 extra salaries to distribute around... shouldn't that money convince the useful people to stay?

I once worked for a company like this. They had a large system written using a language that had no viable upgrade path. They needed to lift out their business logic into a more durable language. CeeLanguage was one plausible choice. SmalltalkLanguage was another. But they had to do something, or die slowly.

I fought long and hard to turn thinking around. It wasn't easy. It was my first programming job ever, so I lacked the experience to argue as convincingly as I might have. But nonetheless, I managed to overcome one objection after another.

The MD finally came out with his real objection:

"If we train people in a more commercially useful language, they will leave and work elsewhere for more money"

I was out of that door as quickly as my feet could take me!

The final result? They could not compete and died slowly. The company eventually sold out (on poor terms) to a competitor, and was wound up altogether earlier this year (2002).

The moral for me? Companies who adopt this attitude will fail. It might take years (it took this company years) but they will fail, and do their employees no good in the meantime. If you see this attitude in operation where you work, get out. Get out now, and don't waste time trying to change people's minds. My only regret about leaving is that I didn't see what was really going on in the MD's head a year earlier, so I could have left then. [Why didn't you recommend Smalltalk or Lisp? You could've been 5 times more productive than your C competitors, and still had a language that's "not commercially useful". -- JonathanTang] If you had left a year earlier, you would have missed out on the experience that led you to this valuable insight. All learning involves discomfort. Consider yourself fortunate to have had this experience early in your career. Some go a lot longer before learning, and then they get stuck.

See also MenDownaHole, OutsourcingWaterfall, PlugCompatibleInterchangeableEngineers


View edit of April 14, 2006 or FindPage with title or text search