Outstanding Objects (Developed Dirt Cheap) 397
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."
Simple explanation (Score:5, Informative)
Rick
Re:Simple explanation (Score:5, Funny)
Re:Simple explanation (Score:4, Funny)
Re:legal issues (Score:5, Insightful)
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....
Re:legal issues (Score:3)
Pascal is a girly-man's language...strong typing is for people with weak minds. If I want to shoot myself in the foot, I don't want my language telling me I can't shoot myself in the foot, dammit! :-)
Re:Simple explanation (Score:2)
Especially when it comes to perl, where the more times you use "use", the slower your code runs per instance.
Re:Simple explanation (Score:5, Insightful)
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.
A few reasons (Score:5, Insightful)
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?
Re:A few reasons (Score:2, Funny)
Re:A few reasons (Score:3, Insightful)
2) Since when can't GPL'd code be used in any commercial application?
3) I'd have to agree with you on this one tho
Re:A few reasons (Score:5, Insightful)
5) Integrating foreign code can be more work than just writing it yourself.
Re:A few reasons (Score:2)
I am quickly losing my mind trying to track down poorly written documentation through conflicting and dated sources. And nobody puts any friggin' useful comments in their code. Hell, it took me the longest time to find out that auto_ptr's aren't meant to go in container objects, w
Re:A few reasons (Score:3, Informative)
The tedium factor (Score:5, Interesting)
If the problem is NOT interesting, I have a lot more motivation to find someone else's code that I can use; if I find a quality solution, I can plug it in, spend hopefully minimal time debugging and testing it, and move on.
And there CAN be pride in using someone else's code, actually; I really get a kick out of using libraries and sending back elegant enhancements or bugfixes back to the authors ("Your library was excellent. I improved it.").
Also, if the code you found is really good stuff, it might help you to finish up a complex feature in record time, which also feels nice ("Oh, I almost forgot to mention it, but that new report we scoped out yesterday is out on the test server").
Re:A few reasons (Score:4, Interesting)
Re:A few reasons (Score:5, Insightful)
What's there that doesn't make any sense??
Your company doesn't trust "public-domain software", but codes in Perl??
AC/DC (Score:5, Funny)
Re:AC/DC (Score:5, Funny)
Re:AC/DC (Score:5, Funny)
Re:AC/DC (Score:2)
Check out their site at http://www.acdc.com
Re:AC/DC (Score:3, Funny)
FIRE!
Re:AC/DC (Score:4, Funny)
Outstanding objects, and they're developed dirt cheap
Outstanding objects, and they're developed dirt cheap
Functors... serialization... patterns...
Developed dirt cheap
Regex... templates... iterators...
Developed dirt cheap
The catch-22 of code reuse (Score:5, Insightful)
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 [sourceforge.net]?
(it's a rhetorical question
This is ridiculous rationalization (Score:2)
Re:The catch-22 of code reuse (Score:5, Insightful)
Of course, the humor is that you find yourself writing wrapper layers for wrapper layers.
Re:The catch-22 of code reuse (Score:3, Informative)
And that leaves you with an application having an efficiency similar to that of a big SUV. OK, so I do it too, but that's no excuse. ;)
Re:The catch-22 of code reuse (Score:2)
It used to be the computation cycles were incredibly expensive things, and programmer work-hours were relatively inexpensive in comparison (well... I don't mean literally cycles compared to hours... but say billions of cycles compared to hours or some such). Of course, in today's world, the time of a *good* programmer can be fairly expensive, whereas big fast computers are fairly cheap. When you look at
Re:The catch-22 of code reuse (Score:2)
Re:The catch-22 of code reuse (Score:3, Informative)
What I was saying about wrappers for wrappers was meant to be just sort of a joke... pointing out the fact that if you are making a wrapper around some standard tool to tailer it for your own use, you have no idea what that tool is in fact a wrapper around, itself. Just the irony of building a black box around a black box creating a new b
Re:The catch-22 of code reuse (Score:2)
Just a simple example: I was looking for a good C++ class that would encapsulate the mess that is the Windows Registry. There are several out there, but they all manage to drag in massive functionality or frameworks that I am not currently using and would prefer to avoid. I am not going to start using MFC just to read a few registry values.
The C++ string mess in Windows makes me cry every time I have to deal with it. I'm sick to death of converting between BSTR, TCHAR, WCHAR, char, CComBSTR,
And this is why... (Score:2)
I personally am firmly against object reuse. Unless it's really plain simple objects like smart pointers.
Unfortunately, I am working right now, and can't go in depth about what I think of this... if you wanna flame me, go ahead, maybe it'll summon up the courage in me to explain better. If on the other hand you know what I'm talking about, please explain to the rest of the world on my behalf... =)
One word, half a wit. (Score:2)
SCO
Very Interesting... (Score:3, Funny)
---
I read your email...
Three Words... (Score:3, Insightful)
Not Invented Here.
Re:Three Words... (Score:2)
Sometimes it's Not Invented by Me.
The trick is knowing when to reuse and when to reinvent. Neither approach is the best one the majority of the time.
Re:Three Words... (Score:2)
49% of the time, reuse
49% of the time, reinvent
2% of the time, PARTY DOWN!
I don't know about others (Score:3, Interesting)
some times it's not appreciated. but hopefully people eventually come around.
Why wheels often reinvented (Score:5, Interesting)
library uses wrong language
library has the wrong license
library pulls in too many external dependencies
library not threadsafe
But it's worth the search - occasionally you find a real gem.
o Coder is too stupid to know how (Score:2)
Re:Why wheels often reinvented (Score:3, Insightful)
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.
Re:Why wheels often reinvented (Score:5, Informative)
use POE;
use POE::Component::IRC;
use LWP::UserAgent;
use HTTP::Response;
use HTTP::Request::Common;
use URI::Find;
Each of which probably use a good number of libraries themselves. Running perl -wc on the script takes
Hell, check this out:
$ time perl -e "use POE"
0.23s real 0.21s user 0.01s system
Sick.
Re:Why wheels often reinvented (Score:3, Insightful)
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
Maintaining Existing Software (Score:5, Insightful)
Re:Maintaining Existing Software (Score:2)
Yeah...it's always a pain when you guess the drugs wrong too. If you don't take the exact same drugs, you still can't understand the dude's code.
I was *really* unproductive in my job when I spent a long time taking the wrong drugs...darn, that was a crazy week.
Finding it is HARD (Score:5, Interesting)
There are many mechanisms that can assist such as:
1 - technical reviews. When these happen, you get a number of co-workers together to review your work. Not only does this assist in ensuring that direct work (architecture, design, code) is correct, but it also provides an opportunity for all those involved in the review to search their knowledge of pre-existing "parts", be they architectural, design, or actual code, and to suggest you investigate them. Of course, if you're like me, then actual review meetings where a number of people sit down and examine your work just do not happen any more. Thus this form of identifying existing work that can be reused no longer functions.
2 - CASE tools
3 - personal memory - only works for those items you already are familiar with, which frequently gets voided when changing jobs.
4 - institutional memory - this is similar to the technical review mechanism, yet is less well defined. The real question here is HOW does an individual tap into an institutional memory? Documentation search? This is far less than perfect even if all work was well documented. Code search? Even worse at turning up matches to needs.
So... the bottom line is that it truly is VERY difficult to match up needs of a software development effort with the existing software that is available.
Once case in point... I worked on a very large project for an FAA (Federal Aviation Administration) contract. One mechanism I needed was a circular buffer/queue. These seem very straight forward to implement, and an obvious place to use an existing piece of design/code. Well, even after extensive search and review I could not find such a part and built my own. Later, I discovered there were at least six independent implementations of a circular buffer/queue in this single project team. All of them were general enough to meet the other implementation's needs, yet somehow none of us knew of the others' overlapping work. If we couldn't coordinate the reuse of these six independent efforts (and that means we all built the same basic algorithm, found the same set of bugs... and yes, using our code management tool I was able to see the same bugs being fixed in each implementation... and thus a total and unnecessary duplication of effort), how in the world will we ever solve the problem of reusing work outside the single project team, or outside a company?
There are some examples of wild success with reuse... though they seem to me to be more success though definition. All of those shell scripts that are built from individual command line tools are examples of reuse, where each command line tool represents a unit of software available for reuse. But, I think we all think of reuse more at the code module level... a function, or class, or small library. And it is at this level that I think we fail miserably, and it is my contention that we fail because we can't easily find the candidates for reuse.
Re:Finding it is HARD (Score:4, Interesting)
Laziness wins out for me... (Score:5, Funny)
Re:Laziness wins out for me... (Score:2)
Dirty Code (Score:5, Funny)
Because developers don't play well with others... (Score:5, Interesting)
It doesn't matter if the code is available from somewhere "out there", from inside your company, or even from inside your group. The reality is that developers in general don't play well with others. Why? For a number of reasons.
First, it is no fun to use someone elses code. This is why at one time Apple computer (many years ago) had 13 different (yes, I counted them) memory managers being written. It was fun to write a memory manager, to solve the problems involved, etc.
Second, people don't trust one another. How do I know that you have implemented this code correctly? How do I know that you will deliver the modifications that I need? That you will deliver them on time? I can't, so it is better to do it myself.
Bottom line, we don't play well with one another, because we want all the fun for ourselves and because we don't trust the other folks (called flipping the bozo bit in some corners).
Are you projecting? (Score:5, Interesting)
Most developers probably don't even know how to search CPAN or install a module from it (or PEAR for PHP). So they roll their own inferior solution. Those who have spent the three minutes reading the docs are getting an incredible benefit.
Re:Are you projecting? (Score:2)
I think this is true. Add Java to that list -- which is ironic because Java was supposed to make code reuse so much easier. Better, more descriptive, more searchable docs would help. Not that I'm any better. I wish I knew better how to find what I need.
Re:Are you projecting? (Score:4, Informative)
Reinventing the Wheel (Score:2)
Re:Reinventing the Wheel (Score:3, Insightful)
Which is pretty much what happens everywhere...
Playing with metaphors (Score:5, Funny)
We reinvent the wheel because new wheels look sexy, not because they roll any better.
I have absolutely no idea whether there's a point to be proved with that, but it's kinda interesting.
There is a very practical reason (Score:5, Insightful)
Re:There is a very practical reason (Score:3, Insightful)
Re:There is a very practical reason (Score:2)
Sometimes, that's simple. I think a lot of developers just don't even want to have to try to understand somebody else's solution.
Oh ya, and then there's that ego thing.
Cause the way software development is taught (Score:4, Funny)
2. They are taught the complete spectrum of software development from function to complete program. So they think that they can do it all reallllly well.
3. They don't get in the habit when they start.
4. They get paid by the hour not the thought. (sorry thats an old lawyer joke.)
Library bloat (Score:5, Interesting)
I write a program, and part of it needs to simply read a
Do I _REALLY_ want to pull in libpng and libSDL just to do this? What kind of risks does pulling these libraries in add to my project? How much will this bloat my code? Will users be confused from the different versions of these libraries? What if I one day want to port to a platform that these libraries work on?
Turns out it's usually simpler, easier, and less risky to just roll your own.
Re:Library bloat (Score:5, Insightful)
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.
Re:Library bloat (Score:5, Informative)
import sys
from qt import *
a=QApplication(sys.argv)
img=QLabel(None)
im
a.setMainWid
img.show()
a.exec_loop()
9 lines.
You're welcome.
It would probably have been even shorter in Perl.
'Bloat' is not knowing the right tools for the task.
Re:Library bloat (Score:3, Informative)
You're going to write your own code to read PNG files?!? Just how much time do you have to write code and fix bugs?
How much will this bloat my code?
You think that rewriting the code will take less space then interfacing to an existing library?
Will users be confused from the different versions of these libraries?
Much less then the users will be confused when they run into a file that you can't read and all their other programs can. All
Think of it this way (Score:3, Informative)
First, the PC came with this video card I didn't like, so I went out and bought a different one. The OS that came with this OS don't use, so I have to reformat the hard drive. The case was also ALL plastic and it was hard for me to drill some clean holes into it for my modding. I had to go out and buy a different case. In fact, i spent my time reassembling the whole darn thing just to make it fit my needs. I should have just built it from scratch and save alot of time!
That's why I don't like to use someone else's code. Now, I would LOOK at their code and see how it works, and then write my own to work the same way. If I am lucky, their code is already the exact way I want it, but it's very rare.
Very modular codes however, are useful at times. THe only problem is that it comes with other crap u dont need and takes up coding space, but that's just nitpicking when you dont have any time.
if developers shearched litterature... (Score:2)
Another problem (Score:3)
Sometimes it IS easier to build a wheel... (Score:4, Insightful)
That's nice (Score:3, Insightful)
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.
You cannot do it better (Score:2)
Try to rewrite LWP or DBI yourself with no peeking. If you have something even 50% as good as these modules in two months of full time coding I will be amazed.
Its exactly the best coders who make heavy use of CPAN.
Documentation (Score:2)
Obviously this will vary depending upon how complex the stuff is. But for a lot of simple stuff that's why. Those of you who haven't had the joy of debugging someone else's code might not r
I generally find creating faster than borrowing (Score:2)
A lot of my projects are AI and/or web based. Web based apps are too damn terse to be bothered. (Anything more sophisticated than a pretty database query ought to simply message pass to something beefier.) AI programmers think that every project require writing their own custom database engine. I general
Re:I generally find creating faster than borrowing (Score:3, Funny)
This is the first time I have ever seen a tagline of this form that I could agree with and feel was a reasonable statement. Aren't these supposed to be ridiculously overstated?
Same reason I didn't reply to another post. (Score:2, Informative)
Quite often it is easy to pull in someone elses library to work with your code. Though note, libraries. Libraries are designed to have some reuse to them. But the library has to have a static API that isn't going to change, which isn't always a safe assumption.
Another aspect is refactoring. Here at my current job I have spent the last month refactoring one of our applications. I used a lot of conce
Time to Understand sometimes time to create (Score:2, Informative)
Half the fun... (Score:2)
Granularity (Score:3, Interesting)
The problem is granularity. I interpret from the title (and nothing else, since I can't RTFA) that they want to reuse individual classes rather than entire projects.
I _hate_ the fact that every UML diagram begins with a blank sheet of paper and that individual classes are almost never reused.
Individual classes, however, are even harder to reuse than whole libraries. In theory you could take somebody's generic model of, say, a Person, and extend it with the extra things you need. As long as Person were well-written it might actually be reusable.
But in practice, it won't extend the classes you need it to extend, and it'll probably be tied in to a vast array of other classes that you simply don't need, making your life very complicated. Since requirements gathering is far harder than code writing, people who have to gather their own requirements generally just end up writing the code to match, since it's a trivial effort.
You lose a lot when that happens: you can't reuse a lot of other processing code that you want. However, how long will it take to find that code? Days, plus the time it takes to adapt? How long would it take you to write it yourself?
The lower the granularity, the harder reuse is. I'd like to see better, but with present programming languages it's not going to happen.
Solving a different problem (Score:3, Interesting)
I do, however, try to find those libraries before reinventing the wheel. Occassionally I do find one that will work, and then I'll be faced with integrating it into the project. At that point, I've always found it beneficial to go through and edit the source, for two reasons: 1) a consistent coding style throughout the project makes it easier to maintain, and 2) I tend to learn a hell of a lot by actually trying to understand what I'm editing. Then, maybe, next time I can reinvent the wheel all by myself.
Because it's a waste of time (Score:2, Insightful)
So unless the code is EASILY FINDABLE, WELL DOCUMENTED, and USEABLE, then it's MUCH faster to do it yourself.
"components", not "objects" (Score:2, Insightful)
Why developers don't reuse (Score:5, Insightful)
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
Wheels are constantly redesigned (Score:2)
The time is also better accounted for... (Score:4, Insightful)
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
reinventing solutions w/ well known algorithms (Score:5, Interesting)
graphics boards and my first task was to debug
the "polygon fill" routine in their firmware.
It turns out they use their own "home brewed"
algorithm that was slow, memory hungry, and didn't
handle degenerate cases correctly. If anyone in
the company would have taken the time to pull
any one of the graphics textbooks off their shelf
(e.g., Foley, van Dam) they would find a much better
solution.
I ended up rewriting the module myself using
the classic solution -- it was faster, used little memory,
and handled degenerate cases reasonably.
It was my experience that everything was a badly
reinvented wheel when I worked there.
Blah (Score:2, Interesting)
The library is under a license other than the MPL or LGPL.
We try to make the library work for hours, only to find it doesn't do exactly what we need, or is horribly broken.
We try to use the library, but it's broken, and the developer lives in France and only responds to emails while we're asleep.
It would be faster for us to write our own then to decipher someone else's code.
The only real third party library we use mostly does the job, but we had to wrap it and impleme
Because sometimes it makes sense (Score:3, Interesting)
I spent a fun week exploring through the computer graphics repositories of the time (it was some years ago), but I finally decided I'd had enough fooling around, so I hacked out some quick C and converted the files.
The converter I wrote and debugged in a couple of hours was virtually guaranteed to crash and burn on any WTK NFF files but those, but I didn't care. What I needed was those files in Inventor so I could get on with the job of lighting and animating them.
That's the problem with the Booch Components and a good percentage of the things I see out there in the repositories today: they solve the general problem with such elegance that they're really optimally useful only for people who want to understand the general problem instead of knowing exactly enough to solve the specific problem they have.
Well, here's a news flash: a good part of the time I'm to busy to learn how to solve the general problem. What's more, I know I'll never need this knowledge I acquire again, so a quick in-and-out of my brain is all I need.
--
The end
Tool makers... (Score:3, Informative)
The knowledge required to get the wrench to work best required understanding several mechanical principles that he was particularly good at, and I am sure that there are others these days as well, mostly working directly for the automotive companies. (Either that or they have much better engine designers who have made it simple to get to all nuts and bolts without special tools. Looked under your hood lately? Which do you think is most likely.)
In any case, the common idea is that if you are going to make something that fits a custom need, you are unlikely to be able to do it with off the shelf components and tools. Occasionally there may be a nice general tool that would suffice for the job, in software it might be a component of MSfts
That's my thought, I could be wrong.
-Rusty
Two Reuse Stories (Score:5, Interesting)
Two years ago I was developing online courseware for a company that trained/certified future medical transcriptionists. We needed to develop a typing test. Now, a typing test is all about doing two things -- (1) noting when someone types something the shouldn't be there and (2) noting when someone doesn't type something that should. So you're comparing for absensces or additions between a given text and a key. Sound like anything else? My first thought was 'diff'. My second thought was Perl (after all, this is text slinging). My third thought was CPAN. And sure enough, Mark Jason-Dominus' excellent Algorithm::Diff saved me at least days of time and quite possibly weeks.
Now, this was possible in part because I was working as a contractor, and so was probably trusted a bit more, and also, in part because my supervisor/contact with the company was pretty savvy. I can contrast this with some other experiences. Like the company I worked for that wanted a webserver log file analysis package. Again, lots of text slinging, but perl or any other scripting language was out because we wanted the source as closed as possible. Nope, it had to be in C, and I was discouraged from trying to find a regex library to use. I essentially ended writing my own regex engine. It was buggy. It needed optimization. The syntax was less powerful . The stats package itself was good, especially for 1997 (it could do things I've only seen other log analyzers do in the last two years), but because it all ran on top of this flaky regex engine, it couldn't fly. I think it got canned after I left... nobody wanted to touch it. I seriously think I lost months of my life on this, and the company lost a good product. All from trying to reinvent the wheel...
Leaky! (Score:3, Interesting)
Where is this good code I'm supposed to use? (Score:3)
Reason 1: Most free source code is crappy. When looking for C code, for instance, you'll hardly ever find any that bothers to check the return value of malloc() and other functions that might fail.
Reason 2: Even when the code isn't crappy, it's usually not adequately commented.
Reason 3: Even if you find that rare piece of code which is both well-written and adequately commented, chances are it's not documented.
coders should not decide to reuse (Score:3)
I think I made it clear: it's a job of system architects (or technology evangelists) to study the sources, to look for patterns, to evaluate patterns, using pattern knowledge to evaluate the source code, and, working very closely with software requirements, design and specs, to decide that some code is good to be reused or not.
Decision to reuse the code requires another style of thinking than most of coders have. Don't assign such job to coders unless coder's and architect's skills are combined in the same brains.
Risk. (Score:3, Insightful)
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
An analogy (Score:3, Insightful)
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.
Fear. (Score:4, Interesting)
Or get caught in some strange license restriction they didnt understand. Since few coders are lawyers its easy to quickly 'get into trouble'.
Not many things worse then having your work ( or your job if you are a captive coder ) deemed useless due to an 'oversight'.
While it sounds simple, with the current state of affairs in the world ( example SCO ), for some its just not worth the liability risk.
Someone should apply this to other fields (Score:3, Insightful)
Just don't get me started on Pirelli or Michelin.
Microsoft: Great Code Reuse (Score:3, Funny)
learning to read? (Score:5, Insightful)
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.
My opinions (Score:3, Insightful)
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
Re:reinvent the wheel! (Score:2)
Re:Laziness (Score:5, Funny)
I completely disagree. As a matter of fact, I have an article that totally disproves this, but I don't feel like finding it right now.
Maybe after my nap.