APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

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 pointers to 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. 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 and 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..



Got something to add? Send me email.





(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> -> Sometimes you should reinvent the wheel

3 comments



Increase ad revenue 50-250% with Ezoic


More Articles by

Find me on Google+

© Anthony Lawrence







Fri Jan 25 13:50:07 2008: 3531   drag


Hehe. A hell of a lot of people are programmers who don't think of themselves as programmers.

A person embedding macros into a Word document?
Programmer

A person whiping up some batch file to make it easy to install some old DOS application?
Programmer

A person building some expense report in a spreadsheet and is using those mathmatical functions?
Programmer.

They may not think of themselves as programmers, but they are. Professional programmers, as in people who pay their bills through programming exclusively, aren't these godlike people that know everything.. most of the time they only know the deep technical details of the portion of the program they are working on at the time.. with stuff outside their scope they are often as lost as everybody else. So it's not like a normal person working on a computer, with limited knowledge, can't be a programmer also.. They are just a different sort of programmers. But fundamentally you are passing instructions to the computer to produce a specific output.

Data in, modification, Data out. == program.

Personally I wish more webdevelopers would take the 'programming' aspect of their jobs much more seriously. If they took time to understand the stuff they are working with then we wouldn't have so many vunerabilities.

For a lot of popular PHP apps they have been riddled with bugs and security issues. Lots of times they do get fixed in a timely manner... but web developers are failing to keep their programs up to date and are costing their customers money and respect when somebody injects a Javascript hack into their website to install malware on visitor's PCs. Or pulls data out of the database and starts ripping off visitor's credit cards. These sort of things can put online stores out of business.

Most of this stuff is trivially easy to fix. For example almost all large frameworks have VERY easy ways to filter and validate user input and prevent code injection vunerabilities or cross site scriping vunerabilities. This is something fundamental to web frameworks, but you have to be aware of them. That means actually reading the documentation and studing some of the code your working iwth.



Fri Jan 25 13:55:15 2008: 3532   TonyLawrence

gravatar
Right you are: (link)



Sun Feb 8 13:50:08 2009: 5345   TonyLawrence

gravatar
Here's a bunch of folks who like reinventing wheels:

(link)

------------------------
Kerio Samepage


Have you tried Searching this site?

Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us