re-use overhead can be worse than re-inventing
on
Finding New Code
·
· Score: 1
Most of the time when I'm looking for source code, it's just to get some examples of how other people have dealt with a particular problem, or when figuring out how to use a new API. Only rarely have I been able to just drop in someone else's code and have it work as-is. There are usually dependencies/conflicts to work out, or incompatible parameters (arrays vs delimited buffer, etc). The sample code may also be tied to a sample GUI, which would need to be merged with my own. Or hacked severely to work as a console/server app. Many times, the time spent understanding the code well enough to modify it would have been better spent re-inventing the wheel.
This isn't to say that re-use is always bad. I've used things like pkzip and zlib libraries and saved a _lot_ of time (and some of my now-scarce sanity).
On the other hand, some libraries pack so many features (e.g. Stingray) that implementation can be rather involved. Nothing against Stringray -- they make some very difficult stuff fairly easy to do. But for the first project I used it on, we were only using a small subset of the capabilities and the overhead of learning the API, adapting to their updates/upgrades and rebuilding/distributing the library modules outweighed the advantages. Especially over the life of the project, which evolved from Visual Studio 6 on Win98 to VS.Net on XP. There's also been significant turnover in the development team over the years, adding to the learning curve.
A company I used to work for had a tradition of handling layoffs (about 5 of them by the time they sold the business) on Fridays. After the first couple of layoffs, we discovered that the MIS guy (Roger) was coming in late on the preceding Thursday and backing up the HDs of the soon-to-be-unemployed. One of my coworkers wrote something that would display the time of the last bootup (this was in the days before Windows, so simply examining the security event log wasn't an option). He'd installed his program on a Thursday and was amused/horrified on Friday when he discovered that his machine had been turned on late the night before. I called me over to confirm that his program was working properly. It was. He confronted Roger about it. Roger looked surprised, but had to deny any knowledge of it. My friend was laid off that afternoon, but was cheered up by the success of his detective work and the fact that at least he had a few hours warning.
Yeah, right. Have you gone to a bank lately? At least the ones around here rarely open before 9:30am or stay open past 4:30pm (4:29 if you're running late with an important deposit).
Slashdot Mirror
Most of the time when I'm looking for source code, it's just to get some examples of how other people have dealt with a particular problem, or when figuring out how to use a new API. Only rarely have I been able to just drop in someone else's code and have it work as-is. There are usually dependencies/conflicts to work out, or incompatible parameters (arrays vs delimited buffer, etc). The sample code may also be tied to a sample GUI, which would need to be merged with my own. Or hacked severely to work as a console/server app. Many times, the time spent understanding the code well enough to modify it would have been better spent re-inventing the wheel.
This isn't to say that re-use is always bad. I've used things like pkzip and zlib libraries and saved a _lot_ of time (and some of my now-scarce sanity).
On the other hand, some libraries pack so many features (e.g. Stingray) that implementation can be rather involved. Nothing against Stringray -- they make some very difficult stuff fairly easy to do. But for the first project I used it on, we were only using a small subset of the capabilities and the overhead of learning the API, adapting to their updates/upgrades and rebuilding/distributing the library modules outweighed the advantages. Especially over the life of the project, which evolved from Visual Studio 6 on Win98 to VS.Net on XP. There's also been significant turnover in the development team over the years, adding to the learning curve.
Don't forget "Hardware Wars". This SW parody is great. http://www.imdb.com/title/tt0077658/
A company I used to work for had a tradition of handling layoffs (about 5 of them by the time they sold the business) on Fridays. After the first couple of layoffs, we discovered that the MIS guy (Roger) was coming in late on the preceding Thursday and backing up the HDs of the soon-to-be-unemployed. One of my coworkers wrote something that would display the time of the last bootup (this was in the days before Windows, so simply examining the security event log wasn't an option). He'd installed his program on a Thursday and was amused/horrified on Friday when he discovered that his machine had been turned on late the night before. I called me over to confirm that his program was working properly. It was. He confronted Roger about it. Roger looked surprised, but had to deny any knowledge of it. My friend was laid off that afternoon, but was cheered up by the success of his detective work and the fact that at least he had a few hours warning.
7:30am to 6pm
Yeah, right. Have you gone to a bank lately? At least the ones around here rarely open before 9:30am or stay open past 4:30pm (4:29 if you're running late with an important deposit).