Unfortunately a lot of people, especially non-technical managers, in IS do not share this outlook. They have the idea that there is a pre-made component for every job. Component, snap-in, DLL, activation object--the list goes on. Your work is practically done. Just hobble together enough of these components and your application is complete. This is the way a lot of managers think. Even worse if you are tempted to write something yourself they begin to harbor the idea that you are deliberately delaying or jeopardizing the project.

My experience is that the time gained using other's people code is usually lost writing workarounds for their bugs. Sometimes a component works out, but in most cases it's a mistake. This is especially true when more complex, highly interfaced functionality is involved. A perfect example is the graphics toolkit I tried to use for our product last spring. At first it was fine and drew the plots we needed, but I kept bumping into limitations and problems. Text placement could not be controlled easily; the colorbar was in separate frame and auto-located, often overlapping other parts of the plot; certain labels could not be turned off. The list of hassles and little bugs grew until I gave up and wrote my own plotting routines. In the end I found that writing the actual plotting routines was much easier than I thought it would be. Most of my time was spent on the plumbing--managing the data and getting it to the routine--not writing the actual plotting logic. Writing the routines myself also resulted in a seemless fit with the rest of the program and inclusion of a lot of special features we wanted. Overall the whole experience was a validation of the do-it-yourself philosophy.

Another good example I remember was the comm package we used in a VB project I did five years ago. In VB at that time there was no support for TCP or networking so one had to use a third-party DLL. We used a top-of-the-line package but nevertheless it was workaround city. I spent a lot of time fooling around trying to ascertain that thing's behaviour--time that I could have spent coding. In the end a lot of the little glitches in our product were traceable to that unit. In retrospect it might have been smarter to write our own DLL, even though that would not have been a light undertaking.

Components are not all bad. I used TrueGrid Pro repeatedly and successfully for many years. Sometimes a component works out well if it is solid and its functionality can be isolated. Your risk is directly proportional to the complexity of the component and the breadth of its interface to your program. Also, when you have less ability a component can compensate. When I was younger and not as productive I definitely used components more. Even then however I was smart enough not to touch monstrosities like Crystal Reports. Back then Crystal Reports was a mere VB OCX, but even at that time was clearly so complex that I would be better off custom drawing to the printer which ended up working very well. Since then Crystal Reports, now an enterprise involving hundreds of millions of dollars, has turned into a huge monster involving entire server machines, clients and SDKs with literally thousands of calls. Seagate (its owner now) sells it as so easy managers can design their own reports. Hah! What a joke! The CORBA infrastructure alone in that behemoth makes it so complex that it is hard for me to imagine a successful implementation. A programmer could spend their whole life just debugging the RMI interfaces trying to get it to work (and I know because I was a CR victim). A lot of complex "enterprise" components fall into this same category. Who pays for this stuff? I think it is like voice recognition software. Uninformed people (ie non-programmers) buy it not because it works but because they like the idea.

I have to admit that I was influenced early on with a do-it-yourself attitude by the master himself, Bruce Molay. When I was a young man I worked at a company called Cambridge Automation (aka Cambridge Digital) which employed Bruce as the resident coder. Bruce was incredible. I remember one day looking over his shoulder as he was generating some accounting reports and noticing what a nifty interface the accounting system had I asked where we got it since it had no visible brand. Bruce said, "I wrote it". Not only had he written the accounting system single-handedly, but also several of our products such as Schedule, an early and important commercial Unix program. In 2002 he published a book called "Understanding Unix/Linux Programming". Seeing Bruce in action made me a believer in the power of the individual programmer.

Using other people's code is an inevitability, but whether the alien binary is at your mercy or the other way around is what makes all the difference.