Slashdot Mirror
Outstanding Objects (Developed Dirt Cheap)
Mark Leighton Fisher writes "Some readers might be interested in
Outstanding Objects (Developed Dirt Cheap); or "Why Don't Developers Search the Literature?" It seems like I still see a lot of wheel reinvention going on, even with the wealth of code and information now available on the Net."
1) There's no pride in using someone else's code.
2) GPL'd code can't be used in commercial apps (blah blah, technicalities, yeah yeah, just try to get it past your boss)
3) If you're paid by the hour, what's the rush?
If it's generic enough to be scratch your particular itch, you'll need to do a lot of work to implement the specifics of your case. If it's very highly specialised, you'll need to do a lot of work to adapt it to the specifics of your case.
;)
Given the choice, would you rather work on adapting someone else's code for your situation - or would you rather write your own from scratch?
(it's a rhetorical question
"None are more hopelessly enslaved than those who falsely believe they are free." -- Goethe
It's far easier for me to spend time recreating code that exists already than to hunt down what's out there, read the documentation, figure out what drugs the developer was on, and customizing it. I make use of perl modules and bits of code on Usenet, just to save time, but that's the extent of it.
You have enemies? Good. That means you've stood up for something, sometime in your life. --Winston Churchill
If your problem is trivial, it's faster to write your own code. If your problem is not that trivial, it takes a lot of time to try to understand someone else's non-trivial solution. More than it would take to write your own code.
I develop in Delphi and I use a lot of stuff from the net (if you want to learn how to create reusable components, and use already made components, this is THE development environment, and there is even a free linnux version! and it is PAscal, not this joke of a language called C or C++).
anyway, as I work that way (for my company), I then get nailed down by the legal team because most stuff on the net doe not have a licence attached to it, or has a wrong licence, or the company wants to kee 100% copyright on stuff, but we can not contact the authors or something like that.
ie: if you develop for a company, you do not have the choice, you have to re-invent the weel (or hide it from your superior and legal teams). what a shame....
... then to find a wheel, see whether the documentation states how many spokes it has, give up and count the spokes, determine what the rights status of the wheel is and, if it's not open source, what the royalty agreement is, convince your boss to license the wheel, compile the wheel, fix the compile errors due to your compiler vendor not implementing the language standard properly, build an adapter to allow the metric wheel to fix on your U. S. Customary hub, test the wheel, discover that it vibrates dangerously at 16.5 mph, try to balance the wheel, and finally give up and build a wheel.
"How to Do Nothing," kids activities, back in print!
That's why patterns are all the rage. It's much more efficient to code within a pattern than it is to hunt down, examine and adapt code written by someone else.
And of course, as others have pointed out, the Not Invented Here syndrome is quite prevalent. It's always more fun to code your own stuff, and it's a learning experience.
I'm not sure I that the 3 reasons Mark Fisher gives for lack of code-reuse are the main issue. Usually I think programmers are just too lazy to search. I had one predecessor that I always suspected had this disease. I've noticed in myself at times too. Usually you think that if you (re)write it, it'll be easier than trying to understand someone else's code (often but not always, you are wrong. :).
That said, let me pass on a little practical story. Having built solutions myself that were quick and dirty, for version 2.0 of a recent project I worked on, I decided to dump most of my code and try building on an existing, well-known open source project in my area. I've spent 4-6 weeks trying to take a well-known piece of open source code that performs a similar function better than my quick&dirty approach. I'm not finished, but with the deadline past and with significant obstacles remaining, I'm really questioning my well-intentioned attempt at re-use.
So let me toss out some more reasons why developers may not "search the literature":
1) the (time)-cost of doing the search,
2) the cost of figuring out the implementation details of what you do find so that you can effectively use it (which can be anything from understanding perl module documentation to understanding the concepts behind lex/yac or some protocol),
3) the time/development-cost of integrating the open source codebase into your codebase; this includes porting or handling dependency chains
4) the risk that, because of some detail that you won't understand until you fully invest in #2 (above), it may end up that this tool you are reusing actually doesn't solve your problems for some unexpected underlying implementation reason (something you can avoid if you fully develop your own solution with methods you *know* will work)
5) the risk of choosing the wrong alternative (e.g. picking one templating system out of the dozen alternatives that then gets orphaned)
I'd like to reuse code more, but rationally there are a bunch of reasons why I don't do more. These need to be addressed more satisfactorily for more code sharing to flourish.
--LP
I think there's also the perception that looking for a library to do what you need isn't work, while writing a solution is.
If you've solved it by finding a library that does it, but it took you a while to find the right library and figure it out, you may find yourself in the hole. Your dept manager may ask "Why aren't you finished? You didn't have to write that component..." and be unhappy with the (accurate) reply of "Well, no, but it took me a while to evaluate the libraries available..."
I'm blessed to be avoiding these at my current position though, so I'm thankful.
-Zipwow
I don't know which is more depressing, that 2/3 didn't care enough to vote, or that 1/2 of those that did are crazy.
It's because all us developers think our way is the better way :P
No, it's because re-inventing the wheel is a lot easier than customizing someone else's utra-cryptic-spaghetti-coded "wheel".
For instance, I was just looking a good SMTP AUTH solution (aka roaming SMTP) that would integrate well into our customized version of qmail. There were a few solutions that almost did the job, but not quite, while offering a ton of extra bloat that we didn't need. A few hours and a hundred or so lines of C code later I had a working solution. Yes, I re-invented the wheel, but it was a whole lot quicker than figuring out and fixing someone else's code, and without all the bloat attached.
My point: Often re-inventing the wheel is good, and sometimes is the only way to go.
Jobs? Which jobs?
Do I _REALLY_ want to pull in libpng and libSDL just to do this?
Yes.
What kind of risks does pulling these libraries in add to my project?
The risk that you will hit a bug in the library. Which is much smaller than the risk that there will be a bug in your one-off k-spiff png display engine (hence, OOKSPDE).
How much will this bloat my code?
It will bloat your code by the additive inverse of the code size of your OOKSPDE. The user already has the library on their disk. If it is dynamically linked to your executable, they pay nothing to use it.
Will users be confused from the different versions of these libraries?
Would you rather they lose data because your broken OOKSPDE doesn't handle transparency properly?
Turns out it's usually simpler, easier, and less risky to just roll your own.
It sounds like you either have a delusionally high estimation of your own abilities relative to those of your library-writing peers ("Of course the code I write will be faster, more correct, and less bloaty than the specialised code that those people who really understand the problem and spend time solving it well!") or you place very little value on your time. Oh well. Have fun writing png-frobbing code for the rest of your life.
When Ford Motor Co. is designing the body for a new model of car, why do they "roll their own" new front fender design instead of just using the front fenders off the '92 Taurus?
I'm not trying to troll, but I thought this article was way too preachy. The author talks about people "reinventing the wheel," but the fact is (to carry the car analogy further) that you can't use the exact same wheel on every type of vehicle. That doesn't mean that you "reinvent" the wheel for each vehicle, but often you'll have to produce a variation on the basic design. Quit agonizing about it already!
So he's been able to find third-party code on the web to reuse in his projects. Good for him. His attitude seems to be though, that if he does it, it must be the Right Way, and therefore everyone should do it.
when programmers are taught to a computer language, we're taught to write. When everybody else is taught any other kinda language, they're taught to read. If I learn Russian, I'll read great literature.
Trouble is twofold.
1) we con't have a corpus of great computer code we can show folks howto read.
2) reading code is most often associated with Maintenance and maintenance programmers aren't highly regarded.
call it NIH.