Somebody or other once made a comment about the value of contracts–those documents that allow us all to state in writing, politely, each and every way we don’t trust one another. (If you find the original, please forward it.)
But, yeah, people seem to find them useful. I just want to point out the harm they do when it comes to writing software.
It usually goes something like this: Company A decides it has some need best met by software development. They either hire an entire team from Company B, or fill a desk or two with prostitutes contractors. The B-team quickly agrees that the problem can be solved with software, and in fact needs new software, and begins billing by the hour.
Now…come on.
The B-team has no incentive to question Company A’s decision to move forward with this plan (which might in fact be why they were preferred over troublesome in-house developers, but we’ll move along). They probably won’t mention it if the entire idea is, frankly, stupid. They have no incentive to produce useful software in a useful timeframe–scope creep is, for them, the Holy Grail. And how about support? Well, see, they’ll eventually (when the contract-renewal business model fails) deliver some clunker of an application, and go away. Beyond that? Not their problem.
I’m not saying contractors are necessarily bad people. Many of them mean well. Doesn’t mean they could get jobs actually writing software, but filling a chair at an hourly rate isn’t such bad work, and maybe something good will come of it.
Oh, okay, fine. I’ll admit it. Some pimps staffing/consulting companies are entirely ethical, and some of their employees are wonderfully good at their jobs. Plus: hearts of purest gold. But how can you tell what you’re getting?
I realize some people hire contractors simply as one part of an empire-building strategy within their own company, but I’m not talking to those people. I’m talking to people who want to get work done and make money.
Let’s look at it from the point of view of an entrepreneur in the consulting/contracting business. We’ll call him Joe. Joe is a good guy, genuinely cares about his customers, and is technically savvy. So he tries to hire the best people, based on their resumes, and put them to work.
Already we have a problem. First, hiring based on a resume is always a risky proposition. Word of mouth works much better, as does actually watching the new guy write code and interact with his team. But Joe often doesn’t really do that, does he? Generally (we’ve been there–but you don’t have to) positions are filled based mostly on word-matching. Got a buzzword in a position description? Is it on the resume? Hired!
Whereas, frankly, if 90% of developers were fired tomorrow–the chair-fillers who don’t write useful code at all, the idea-toy addicts who always seem to find a way to incorporate the last whitepaper they read into every new project, the folks who think “RTFM!” is a good response to users, the prima donna “architecture astronauts” (thanks to Joel Spolsky for the term) who emit a buzzword-stream but forget which project they were actually working on–anyway, if those guys all lost their jobs? We’d get more software written. Better stuff, too.
So, anyway, Joe (remember him?) means well. He does what he can. But Joe doesn’t sell software–he sells a service. It scales only when he adds more people. Soon he needs managers (are they any good at their jobs? how do you measure?) and puts somebody in charge of hiring. Somebody who gets paid according to how many people she hires. Or Joe has recruiters who are also account managers, so they find new clients and staff the new clients’ position requirements with new hires. Even if Joe somehow did everything right…well, he’s not really in the picture anymore. Not if he was making money, anyway.
Okay, so this isn’t news, is it? But, mostly, people talk about how to “manage” this situation. Here at Cabin Fever, we say: bad design begets bad implementation. (Well, no, we don’t really talk like that, but you get the point, don’t you?)
It can’t be “managed” away. It’s right there in the architecture–the whole model is flawed, ab initio, and we don’t want to play that game. How about you?
Contracts suck. Forget the B-team. They won’t do you any good except by accident.
Be First to Comment