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
I still see a lot of wheel reinvention going on...
Not Invented Here.
StrategyTalk.com, PC Game Forums
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.
Except that your training yourself to reinvent the wheel every time, which means you won't know where to look for "conventional resources" when you need them.
Which is pretty much what happens everywhere...
Clear, Dark Skies
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.
Case in point: I spent a week searching for C++ source code for a math expression parser (put in x+5*y, get result). I found ZIPPO, except for 3rd party libraries, and ONE crappy C code from 1997 and ONE C++ code written in German that has a ton of subtile bugs.
So unless the code is EASILY FINDABLE, WELL DOCUMENTED, and USEABLE, then it's MUCH faster to do it yourself.
The intro implies that only OOP can make reusable components. I don't want to start yet another paradigm war, just point out that there are non-OOP component solutions to a lot of things. I used to use extensive math and graphics FORTRAN libraries as an intern long long ago. They were surprisingly useful and easy-to-use in most cases. I am not promoting FORTRAN here in any way, for there are a lot of nasty things about it; but it still allowed extensive component usage before OOP was the thing.
Table-ized A.I.
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
# library pulls in too many external dependencies
BINGO!
i cant count how many times I tried to use a "library" that had 4-5 dependancies that made it 100% useless.
and then you get some that are a Dep hell going 3 to 4 levels deep.
no thanks.
Do not look at laser with remaining good eye.
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?
Sure, it's frustrating to re-invent the wheel and create a custom library of classes when something perfectly useful already exists. However, if it's documented at all, most of the 'free' code I've come across out there looks like: /**
* Fubar formatter.
*
* @param param1 param1
* @param param2 param2
* @return int
*/
public int fubarFormatter(int param1, String param2)
{ [highly obfuscated code to prove I'm a R0x0rz coder dude!!!!]
}
Sure, it LOOKS like it MAY provide what I need, but I couldn't be bothered to figure out if it covers all of the possible exceptions which may be thrown or even if it consistently does what I require of it. Much easier to just design the proper solution and implement it in a manner which is internally reusable.
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.
My company uses M$ SQL Server for our DB (yes we are a microsoft shop ) The server can be configured to send email using Outlook or any MAPI client, or can be configured to use SQL MAIL, which expose extended stored procedures such as xp_Sendmail. But no one looked into it so someone wrote their own sp_Sendmail, that connects to CDO using objects in the stored proc.
I think the failure to understand the capabilities of your tools and configure them is the main reason that people reinvent the wheel. (Outside of general the general "that's good but this way is better" pride we all have.)
I am so creative, look at my cry for attention in my sig.
The point of C is that sooner or later a programmer gets good enough to stop shooting himself in the foot. If he's not there yet, best to stay in the shallow end.
Quite often, the act of comprehending what a bit of "reusable" code is doing exactly takes nearly exactly as long as writing a working example oneself from specification...
And usually, you DO have to comprehend what it does, even when it's supposed to be "opaque"... If only to understand the caveats of performance of the code in question. (Memory use most commonly.)
Using "their" wheel is usually cheaper than inventing your own.
.sig
But sometimes, it's a disaster.
How can you tell if their wheel is any good?
Including it with out evaluating it is a huge risk.
It's not even easy to guess at the risk.
Testing helps, but a good evaluation can be as hard if not harder than recreating it.
How can I know if Net::::Hesiod is the best thing since sliced bread,
or buggy garbage that should have been fixed long ago?
Maybe if some fitness/correctness/bugginess evaluations were made by someone
(even say, comp. sci. students as a homework assignment... )
-- this is not a
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.
$ time perl -e "use POE"
.6 seconds of startup time, then go for it. But unless you writing MacOS or Mozilla or X, it's just not worth it.
0.23s real 0.21s user 0.01s system
If you can reimplement what you need, and never be more then a quarter of a second less effiecent, and never crash or abort where the original wouldn't have (because a crash or abort takes minutes and pisses off the user much more then waiting for the program to start up), and justify spending the time reinventing the wheel over
But even after I've located a mature library, I still feel those jitters that make me want to do things myself. Why? Because my concept of how the problem should be solved, and how the solution should be exposed, rarely aligns well with how the library author exposed it. More importantly, I typically have a pre-conceived notion of how i'll use the exposed solution to build my software.
When I reach this point, I step back and take a deep breath. If I'm looking at a mature library, chances are the conceptual misalignment stems from the fact that the library author understands the problem space far better than I do.
Berkeley DB provides a good example of a difficult problem space exposed intelligently. Shortly after the jitters, I realized that my understanding of databases was sorely lacking; diving into the documentation helped me understand how to structure my thinking about my application's design.
In summary: I think that developers turn back in disgust from new APIs because the API factoring doesn't match the developers' pre-conceived notions.
gimmie a break. Delphi is a desert wasteland of resources compared to C/C++. Delphi isn't even a language, its a product. Borland itself has re-invented more wheels that I can shake a stick at, with their endless wrappers for the Win32 API, COM, ORBs, DB connectivity, etc. The *NIX world is a long standing example of code reuse in both C and C++. Check out the STL, Xlibs, etc.
Just don't get me started on Pirelli or Michelin.
Yeah, but MY way is...oh, wait, it's not funny anymore, is it?
Your courageous and selfless spelling corrections have made me a better person.
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.
Lots of good thoughts expressed already. Here's my list of reasons we don't reduce, reuse, recycle code well:
/can't/ do it better than has already been done.
1. It goes against the unwritten rule of "elegance". Using someone else's code often means it just doesn't fit quite right into your program. We'd rather write our own solution that fits "perfectly" into our program than find and use someone else's solution that isn't quite perfect.
2. Trust. If I'm going to use someone else's code, can I trust that it is (relatively) bug-free? Can I trust that it does what it says it'll do? Without unseemly side effects?
3. It's more fun to write code than to search for code.
4. Hubris: I can do it better.
5. I know I can write my own solution. I don't know that I can find another solution, and that if I do it will work well enough for me (or won't require extensive modifications) and there won't be some other issue with it that will keep me from being able to use it. In short, I know I can develop a solution in n time... but if I spend time looking for and integrating another solution it's a crapshoot -- I might spend n/10 time or 10*n time.
Now let's look at some cases where reuse is working:
- Standard libraries. Popular languages come with a fairly large library of standard code. Reuse works here because (1) there's usually little/no choice and (2) being a standard library, there is a degree of trust given to it that is not granted other code.
- Popular add-on packages. Whether it's Log4J, a CPAN module, or a well-used bit of Javascript. Reuse works here because of trust: if lots of people are using it, it must be good.
- Really complicated things. Regex. Who wants to write regex code? Reuse works here because of the belief that you
- Really big things. Graphics libraries. Reuse works here because at some point a job becomes too large to tackle, compared to finding and using an existing solution -- even if the existing solution stinks.
In short, in order for code to be reused, it must be findable, usable, trustable, and valuable. The last meaning the time/effort spent in finding and learning existing code will be less than the time/effort spent coding a new solution.
That's 2c off the top of my head, I'm sure I can do better but it's late and I'm tired and I'm going to bed shortly.
-Thomas