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."
It's because all us developers think our way is the better way :P
Rick
Making something out of nothing : MD5 ("") = d41d8cd98f00b204e9800998ecf8427e
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?
I wasn't aware that AC/DC was involved in software development till now.
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 read your email...
Who is John Galt?
I still see a lot of wheel reinvention going on...
Not Invented Here.
StrategyTalk.com, PC Game Forums
some times it's not appreciated. but hopefully people eventually come around.
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.
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
I always hit the net before emarking on coding. There's no way I'm gonna spend 6 hours throwing together code that someone else has spent 20 lovingly moulding for me :-) I just too damn lazy... What can I say, Wally is my hero :-)
-- Gaxx
Done Dirt Cheap.
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).
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.
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.
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
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.)
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.
Let me make an analogy between using someone else's code vs. writing your own and buying a (not custom) PC vs. building one yourself (a few years ago).
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.
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....
Ever tried to work a library that does something very similar to what you need it to do, but not exactly? You end up writing more code to get it to work with your program than you would have written just implementing it from scratch. That code tends to be bulky, difficult to maintain, and prone to bugs. Sometimes it's better just to start with a clean slate.
... 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.
Code reuse is a great idea. In theory. Where everyone wants to live, cause everything works in Theory.
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 concepts from the original code, yet the implementation was not what we needed now. Originally the code was used for batch processing. However, the new code which does the same thing is built for a thread safe and high speed processing. The data structures it used originally had a different use.
So, one of the reasons to write your own code is for your own specific purpose. I like to look at other code before I write something, but rarely does someone else's implementation fit the mold for what I need.
Norris/Palin 2012
Fact: We deserve leaders who can kick your ass and field dress your carcass.
Most of us are lazy by nature.
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.
Best Windows Freeware
The time it takes to fully understand other code is often as large as the time to create code in-house. For code created internally, there's someone who understands everything about the module being used. Because of this, if there's a bug in internally developed code, it can often be easier to find and fix than third party code.
Well, I would RTFA if I could RTFA, but I'll try to give you an answer anyway.
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.
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.
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
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.
Back in 1990 I worked for a small company that built
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.
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?
I have been involved in software reuse since the mid-1980s and possibly even earlier. There has been lots of energy expended on the problem of making existing implementations extensible, one of the strengths of OO technology, though not requiring OO. The big piece that has always been missing has been a major concerted effort focused on facilitation matching a developer's needs with existing software.
... I have long felt that CASE tools, yup those tools that are totally out of vogue right now, would be of greatest value if they had a dual function. Their primary function would continue to be as a means of describing architecture, design, or code, but a secondary function would be to, in the background, perform a continuous search of existing work looking for matches. I have never seen a tool that does this, yet this seems a tremendously valuable function.
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.
Some or all of these things happen:
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 implement all of the features it didn't. In the end, we should have just created our own library. The way I see it, it's just one more thing we can sell.
Yes, I'm paid by the hour, but I also care about the quality of that hour. If the problem is interesting, I tend to research other solutions (to scope out the pitfalls and features I might not have thought of), then I'll often implement my own solution, because learning someone else's code tend to be pretty high on the tedium scale.
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").
There are only 10 types of people: those who understand decimal, those who don't, and, uh, 8 other types I forget.
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
My grandfather was a Tool and Die maker. If GM mechanics were having problems tightning down the distributer cap after adjusting the timing, GM would send him a car, explain the problem, he would take a look, make a couple of different wrenches along the idea of what he thought would do the job, then send back the wrench that did the job best.
.NET tool set, that you have personal reasons for not using (can't stand msft, can't afford .NET, can't follow the msft licence requirements, don't like that Craftsman sold someone's pattented idea to Snap-On without paying royalties to the inventor) and so you make your own tool to do what ammounts to the same job.
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
You never know...
One of the biggest problems I usually run into that no one has mentioned yet is this: when searching the literature, I don't know what terms/keywords I should be searching for to find the code to solve the problem.
For example, one project I worked on was an interactive calendar application that would dynamically place multi-day events across the days on which they occurred. Well, I needed those event bars to be as compact as possible, so I searched for an algorithm to figure this out... After 3 days of searching and finding nothing, I asked a Computer Science professor at the local university and he couldn't come up with anything either. I know there is code to solve this type of problem, but I simply couldn't find the keywords to use to locate the code.
And just to chime in about what everyone else has mentioned:
My top reason for not using public code is the lack of quality documentation. If I didn't write it, it's really hard for me to understand it and make use of code without putting in considerable time studying the code, which is more time than I have.
-Adam
I often don't reuse for reasons described very well by other posters, but I wanted to mention some cases where I either did reuse or wanted to.
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...
Tweet, tweet.
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! :-)
20 January 2017: the End of an Error.
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.
Why don't we use more available code? Leaky abstractions for one. And look at the DLL and .so hell we're in now, where we have libraries that depend on libraries which depend on libraries...yik...all that to save a tiny bit of work, ain't worth it. Write your own.
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.)
I use libraries (or modules). However, I don't think I've ever used available source code as a starting point for anything.
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.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
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.
Less is more !
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.
You do have a good point there about owning the code. I've found this repeatedly at my company with using external/free software solutions in general.
.NET & the mono project--should be easier to push this if I can say the same (intelligently) written code will work in Linux).
It's a completely idiotic approach to take. They have no problem paying for a god-awful piece of software that somebody thought was cute, but never bothered to check and make sure it'll support everything we need (or even bother to ensure that it'll scale properly), but they are vehemently against using any type of open source software and discourage use large chunks of external code in your apps.
A lot of this stems from code-ownership. They want somebody that they're paying to come back and blame; whether it be me, the outside vendor, or whomever. It's ridiculous and I've tried to make my case time and time again when trying to deal with some of the morons at support, that if we were dealing with an open solution and I could see the code, that I could figure it out for myself. Sure a lot of times it's nice to be able and call and throw it in their laps, but when you hit that week mark and your support vendor isn't able to come up with a solution and you've reached the limits of what isn't in a binary format, you start to get a little frustrated.
I'm slowly making in-roads though; I can see a lot of managers' concern with using Open-source because if you don't get a support contract, you're relying on your in-house people to support everything, which obviously causes a problem if those in the know leave. But is it really necessary to pay a small fortune for a SQL Server, Windows 2000 Server running IIS to produce some basic web applications when Apache/PHP/MySQL|PostgreSQL are all available out there. (And this is the reason that I'm loving
Ah well, got off topic there, but I'm always a big fan of using external code, but have found repeatedly that I'm not allowed unless I sneak it in and take credit for it myself (which I have/will never do).
Simple, a lot of coders are afraid of being sued later on.
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.
---- Booth was a patriot ----
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.
here here!
and if you can't shoot your foot off (C) how are you going to blow your whole leg off (C++).
And if you can't think of a good reason to do that... well, I think the phrase girly-man was invoked!!
-C++ Troll
Just don't get me started on Pirelli or Michelin.
Some of the best code reuse I've seen is in Microsoft products. On my Win2k PC I have about 20 copies of 5 different versions of MSVCRT*.DLL. Previous versions of Windows had similar reuse of VBRUN*.DLL.
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
I've been writing code professionally for years and now I lead others in system integration and software development.
I see new folks coming in and wasting so much time rolling their own stuff, it just kills me. The cool thing is not to build what others have already built. The cool thing is to make progress, build on what others have built, and provide users with something they can use.
Guess what guys, users don't care if your linked list code is better than anyone else's. Users want things to work. If you can spend more time concentrating on that, and less time finding and fixing the same bugs another guy dealt with two years ago, you will be doing more for users.
Guess what else. Nothing we do is perfect. That spiffy library you get from the net to solve a problem will have bugs. If you write your own, you'll have a different set of bugs.
I think too many new developers have not developed sufficient troubleshooting skills when they were learning their trade. They only know how to fix stuff they wrote because they can't get their heads around how someone else does things. I value the hardware and embedded systems work I've done because it taught me troubleshooting skills I use every day.
I can truss or trace someone elses executable binary and give the vendors / developers clues on how to fix their code without ever seeing the source code. How? Because I've developed an intuitive approach to problem solving based on the simple notion that programmers are lazy and they tend to solve similar problems in the same way. Patters are useful whether they are formal or intuitive and they are useful when developing and debugging.
When my engineers want to use a new technology in our development, I grill them very hard to determine whether they are choosing the technology just 'cause its cool and they want to learn something, or because it will actually bring some value to the product being developed. I'm all for my engineers learning new things, but I don't want them to write a lot of bad code while they figure it out. If they want to use a new technology, I prefer they re-use libs or code that an experience developer in that technology has already built. I think people should try to learn from others examples, and then innovate after achieving basic competency.
I've seen a lot of cases where someone reinvented the wheel, but instead of using an axle, they just put the wheel under the object so you have to move the wheel to the front to keep going, and then to top it off, they made the wheel square or triangular.
I did that once. In 1969 I needed a sort, so I looked in the fortran programming book I had and implemented a bubble sort, to sort records on disks. When it became clear that the sort would take a couple of months to complete, I started working on optimizations. As I was working for a college, one of the profs suggested that I take a look at the collected algorithms of the ACM. There I learned about quick sort and heap sort. I was able to incorporate those, but I had to deal with the fact that I had a lot of data on disk that I couldn't bring into memory. Eventually I got a sort working that wasn't too bad for the times and the computer resources.
Then Knuth published Vol 3 which I studied with my experience in mind. I was amazed to see Knuth develop and analyze my progession of improvements and cite the authors and dates, all of which preceded my efforts by at least 5 years. I also noted that Knuth's statement that the common use of the bubble sort in programming texts was a great crime.
Roll forward a five years and I join a group where a new backup utility has been released which sorts the blocks to be backed up, but there was some sort of stack overflow problem. But I was the new guy who wanted nothing to do with tapes and besides, the two engineers working on it were comp sci graduates and I was a college drop out.
Roll forward another five years and a coworker had been stuck with this code which was still running into some sort of strange stack overflow problem. He's the polite, persistent nagger type, so I reluctantly agree to take a look at the code. In 15 minutes I realize that the code is quick sort, which then means that there is a serious bug in the code because its overflowing a 200 element stack (and if you don't know wny I knew there was a serious bug instantaniously, you MUST NEVER CODE ANY SORT). In the next 15 minutes I found 3 coding errors in the code, 1 was from the original fortran code, and 2 were from editing the fortran assembly to inline it into the module.
If I have a problem that calls for a sort, I can reuse Knuth's research into sort algorithms, which reuses the work of others to create significant advance in the subject, I can reuse the algorithm coding by transliterating the MIXAL, I can find code in various languages from all sorts of sources (which I evaluate by reusing Knuth's methodology), I can call a binary library routine that I may or may not be able to see source code for, but whose bahavior I can check with rules of thumb reused from Knuth, and I can research new algorithms and possibly reuse after reusing Knuth's analysis to verify the claimed advantages.
In my view, reuse is the obvious method to apply to any development process.
As a mechanical designer, I would be foolish to fail to use standard nuts and bolts, and where that's not reasonable, foolish for failing to use standard conventions and standards for screw threads. A mechanical engineer works with dozens of references and hundreds of catalogs.
For a programmer to fail to access reference materials and catalogs looking for existing components and art (craft) to reuse is idiotic.
The problem is that there are few good references to draw on.
The only reasonably comprehensive compendium of computer software algorithms I know of is in the 6-10 books that Knuth has published.
I've opened a number of books where the title suggests a comprehensive listing of software algorithms or C++ objects, and been greatly disappointed at the lack of depth. These books are like going into the drug store or Sears to find the right nuts and bolts for a project. I was hoping for something closer to Home Depot which only scratches the surface of reusuable fastener technology.
Softwa