Monday, October 06, 2003
If it Wasn't Invented Here, I don't want to know
Very funny piece over on JoelOnSoftware covering the merits of DIY coding versus buying/borrowing/stealing someone else's package. The essence: if it's your core competence, do it yourself; if it isn't, give it to someone else. Joel cites the issues of different understandings of what the customer needs, flexibility of imported code and the speed potential of hand-crafted code. It's hard to argue with such compelling logic. After all, if you're in the software game and you are after differentiation, you should start from scratch, otherwise you will just be a me-too clone (how many clones of Half-Life are there? of Quake?). If you're developing new financial products (say for a bank or an investment house), you should do the work yourself because, chances are, if you can get it done fast then you will have a lead on the market. As I said, hard to argue with. But not impossible. The mantra is "If it's a core business function -- do it yourself, no matter what. Pick your core business competencies and goals, and do those in house. If you're a software company, writing excellent code is how you're going to succeed. Go ahead and outsource the company cafeteria and the CD-ROM duplication. If you're a pharmaceutical company, write software for drug research, but don't write your own accounting package. If you're a web accounting service, write your own accounting package, but don't try to create your own magazine ads. If you have customers, never outsource customer service." The key clause in Joel's piece is (and he says it is, so it must be, and he even saves it until the end): "The only exception to this rule, I suspect, is if your own people are more incompetent than everyone else, so whenever you try to do anything in house, it's botched up" So, how might that apply to government? Government has customers, so it should keep customer service; it produces brochures and leaflets, so it should do that inhouse. So many core competencies, so few people to do them? Really? I think Government's core (and only) competency is the handling of the rules by which we lead our lives - and I mean this in the broadest possible sense. The ones that say how much tax you pay, how much benefit you claim, what even-handedness means, what kind of service you should get when you go to a hospital and so on. Anyone department may see all kinds of things as its core competencies, including developing code in house, commissioning bespoke code from software houses or managing and running its own website. But that's a fallacy. Those are not core competencies. They're peripheral to running the rules. Joel is absolutely right. In-house you can write faster, better, cheaper, cleverer code and you can deliver it in no time flat. If that's what you do for a living. But who cares? That's not the point of government. So, for government, re-use is great, reinventing the wheel is terrible. A waste. Even a travesty. The Excel folks may have written their own C compiler as Joel says. That doesn't mean government needs its own version of Excel. But I bet you that there are a few out there. Or mail systems. Or databases. Or CRM systems. And none of them came out of a shiny box.
Posted by Alan at Monday, October 06, 2003