Software Labourers

CategoryAntiPattern

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:

Management. Someone was a secretary to a technical manager and that's enough qualification to become a technical manager.
Team Leading. A trucking company. People who get retired from trucking for medical reasons get made into truck driver team leaders. And from there it's a quick re-org to being a software engineer team leader.
Directors. Yes it even happens with company directors. UK companies in particular have a habit of regarding there being a hierarchy of directors. Managing Director at the top, then Finance Director, then Sales Director, Accounting... all the way down to IT Director at the bottom. I've known people who've 30 years experience at being an accountant. They work their way up through supervising accountants and accounting procedures to become Accounts Director. Next promotion is to Sales Director. A subject they know nothing about...

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

Blissex

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.

Not all such companies fail. IBM does this, as do other Fortune 500s. They just go ahead and throw 10-fold as many labourers on the project right from the beginning (and sometimes surreptitiously hire outside contractors when greater agility/time to market is still required).

[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]

Are you sure he didn't?
- My mistake. I misread "his real objection" as "a real objection", which implies that the OP agreed it was a legitimate reason to not use a real language. I still think that "Teach 'em Smalltalk, it's useless everywhere else but will make us 10 times more productive" is a logical reason, but perhaps I overestimate the intelligence of management. Maybe they'd just come back with "Then how come Microsoft doesn't support it." -- jt
- If he would said that, he likely would have been told that those aren't adequately "vendor supported", and/or that an ArmyOfProgrammers wasn't available. The PointyHairedBoss offering such an excuse wouldn't have been troubled in the least by the obvious contradiction between such a position and a) the fact that the current stuff is even less vendor-supported; b) the company likes proprietary stuff due to employee LockIn?. (If pressed for an explanation, a) could be explained away by noting that the current solution, while also not "vendor supported", is what's already in place; and if this objection were successful in quashing the debate, the boss would have never had to reveal object b - which was his hole card). -- ScottJohnson

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.

CategoryEmployment