But First, Write No Code

Something I see often in person and online are programmers constantly implementing common solutions, reinventing wheels, or embracing NIH.

Before you do this, please consider the Kev009's Oath - "But First, Write No Code". This is a solution to a variety of problems in software development, but today's article is specifically on using external code.

I've found that programmers who follow a system similar to mine (detailed below) develop systems that are more stable, maintainable, and sane. They likely write better code because it means they understand their tools and also read others' code. They examine the problem first rather than going in guns blazing.

Steps to decide whether to use an existing solution or write your own implementation:

1. Scan the area. Google, Freshmeat, SourceForge, standard library, OS libraries, etc. are your friend. See if the problem you are trying to solve has been solved. I don't care how long you've been programming or how much you think you know. The ecosystem of a language is constantly changing. Make a list of hits that look similar to the problem you are trying to solve. Try and get a quick sense of the idiomatic methods of using your language, OS, etc.

2. Do research. Are the solutions you found in step 1 suitable to the problem at hand? Consider the pros and cons of each item. Now, carefully evaluate how idiomatic the items are to your language and environment. If the item is open source, does the community seem active? If it doesn't fully map to your problem, does it look like you can modify it to do so?

   Even if you end up developing a solution from scratch, you should at least now have some good references. Keep in mind, extending an existing project may be considerably less work. You might even be able to offload maintenance of that component. 3. Consider the license. This isn't just for the legal department. What kind of project you are working on will weigh in heavily. Commercial or open source? As a software professional, you need to be abreast with the various licenses in the wild. As an open source developer, you need to consider how licenses will affect your work being packaged by distributions. An open source library licensed under the GPL is not acceptable for static linking to commercial software. However, you can link to an operating system provided copy or bundle the dynamic library with your application. LGPL does not have this restriction. With both of these, you must supply your changes upon request from end users among other things.

   BSD, MIT, and Apache style licenses allow you to make changes and redistribute under completely different licenses. Some just want credit in your documentation. These are very compelling even in commercial development.

   Commercial components may have a per-copy fee associated which may dissuade their use by your organization. If you don't get the source, you won't be able to effectively change or maintain it so you will also be at mercy of that developer.

3. Make a decision. By now, your list should have been pared down based on licenses and research. Perform extensive evaluations of the remainder and eventually hone in on the one you think fits best. You're going to have to rely on your experience and intuition while making the critical decision. Perhaps the hardest part: weighing it against a mythical home-grown solution in your mind.

4. Implement the decision. Self explanatory. This either means bootstrapping your own project or fully integrating the external one. If you are extending an open source solution, consider submitting the patches back to the community for feedback and perhaps integration. If you are bootstrapping your own solution, you've got your work cut out. Is this only suitable for an internal project, or perhaps it would have its own merit as a new open source project?Be sure to reevaluate early and often. That library you chose might turn out to be a can of worms, just as the "easy" new solution you had in your head might require years of development.
5. Subscribe to the announce mailing list. Only if you used an external solution. Does the project have an RSS feed for releases or a low volume announcement list? Don't be like Adobe. Avoid embarrassing security problems. Also consider how enhancements and bug fixes to the external project might make your own project better, more stable, and more efficient. This is where the real lasting dividends of using an external solution come from.

This list is widely applicable. You've got a seriously high bar to reach if you are developing containers of <T>, sorting methods, GUI frameworks, parsers, text and binary file formats, and much more so try and follow it the next time you code.