|
I would never buy a library, but I've never had that option either. Every tool I use is open source, and I build small proprietary applications around the open source stuff. (Making web pages and parsing CSV files is not my business domain, so I let the community handle those.) I will say this -- the first step to not writing too much code is to reuse your own "internal" code. It's simple; instead of cut-n-paste-n-modify, make it a library, and make the per-app "modification" some different parameters you pass to the library. Now a bug that affects all the possibilities can be fixed everywhere at once. And, if someone understands one app's usage of this library, they will understand the other app's usage, as well. Less to think about, less code to maintain, and nothing to buy. The next step is letting other people fix your bugs for you. My last job was for a company that routinely factored out part of their apps into community libraries. If you use Perl, you probably use Moose -- that was a piece of an internal app at one point. Releasing that bit of code changed the entire Perl community, and it made maintaining our software even easier. There are plenty of times I've hit a Moose bug only to have it fixed in 30 minutes by Someone Else. (To be fair, I've fixed other people's Moose bugs too.) So anyway, the word "reuse" is thrown around a lot, but it is really an important concept. I have reused every piece of code I've written in the last few years -- once in my application, and once in the test suite. If you're not reusing your code at least once, you're doing it totally wrong. If you're not reusing your code more than once, you're missing out on a lot of good things. |