Sometimes you should reinvent the wheel

It's an old adage: don't reinvent the wheel. Search Google for "reusable code" and you'll find hundreds of thousands of web posts and books extolling the virtues of both writing and using reusable code.

Well, yeah, there are advantages. If you can save time and money by sucking down a Perl module from CPAN, it's hard not to see that as advantageous. There's also the argument that some tasks are very tricky and hard to do right.. if your skills aren't up to the challenge, you don't have much choice but to use someone else's code. Even if you feel you can write what you need, if there is nagging doubt that you really have dotted all the i's, maybe you should go get the code that has been time proven, right?

Yeah, right. That all makes sense. Except..

Except sometimes it doesn't. This morning I was speaking with a long term customer who had run into problems with his website, mainly because it had been done by a company no longer in business and they used some odd proprietary tool to do all the coding. Rather than try to work through a dead system, my customer decided to just let it limp along and start fresh. He hired a young person (not a programmer, but a "web designer") and in a short time this person created a functional duplicate of what they had and was able to start extending it. Because he was not really a programmer type, he used open source technologies, specifically a lot of PEAR. According to my customer, he did a really nice job.

And then something broke.

Somewhere in the mass of downloaded routines and extensions, something went awry. Probably just some upgrade that wasn't quite right and that caused something else to fail. Minor panic.. my customer called me looking for help. Mmmmmm.. I know a little PHP, but I prefer Perl. More to the point, I know nothing about any random PEAR thingie that happens to be a part of their website. And actually, that's also true of my customer: if it were just straight PHP that he had coded himself, he could debug any problem himself.. but PEAR? That's Somebody Else's Code. All open source, of course, which means you CAN dig into it and grok it, but right now we have a problem that needs immediate attention. There's no time to learn the innards of something you've never seen before.

In this case, there was no choice, at least for the designer. He doesn't know PHP, Perl or any programming language. I might argue that such a person really is not a web site designer (or shouldn't be), but I'd probably disenfranchise most of the profession with that, so I'll let that dog lie. But there's the problem, isn't it? If my customer had hired a PHP guy to write it from scratch, he could probably have debugged it more quickly. He'd still have the problem of understanding Somebody Else's Code, but it would have been ONE piece of code rather than a series of strung together modules. Ideally, if he had the time, he would have written it himself (but of course he has other things to do). Second best would be to hire someone but review and gain at least a casual understanding of the code as it was being written - that also would have made debugging easier.

As it turned out, he was able to track down the problem and fix it - he dodged that bullet. The site is functional, the non-programmer actually learned quite a bit in the process, so all in all it may have been a good thing overall. Still, it can't help but leave you feeling a little shaken..

I've said before that I prefer to write my own code whenever possible. It may not be the best code, nor the most efficient, but at least I understand it - and I don't, I can rip it out in giant chunks at rewrite everything that doesn't work. There are times when I have to use someone else's modules, but I try very hard to avoid that: if I can possibly write it, even if it doesn't work as well as that other code would, I'd rather. I feel safe that way..