Many developers like to create software from scratch, even when there's perfectly good reusable code from other projects, open source, or even commercial products available to do the job. The justification for rolling your own might be ego-driven, based on a notion that no one else will do it as well as you do. It might be a habit, perhaps derived from computer science school projects where students had to create their own compilers so that they'd understand what really happened to code at the machine level.
Whatever the reason, rolling your own code can be a waste of time and effort, as well as an opportunity for bugs to creep in -- after all, new code is more likely to have bugs than existing code that's been reviewed and tested. There are nine types of software projects that really shouldn't be roll-your-own efforts. In order of increasing bad-idea-ness, they are as follows.
[ Ever the autodidact, Andrew Oliver wonders if a computer science degree is worth the paper it's printed on. | Download InfoWorld's PDF of tips and trends programmers need to know in our Developers' Survival Guide. | Keep up with the latest developer news with InfoWorld's Developer World newsletter. ]
9. Your own load test framework (for Web applications)
Outside of a few edge cases (especially for things that are not Web applications), load test tools exist. So why create new ones? For load testing, you have everything from "outsource to us" websites like WebPerformanceInc.com and bloated, painful, but mature tools like LoadRunner. There are even open source tools like Selenium and Testmaker. You may need to create your own load test, but you really don't need to write your own load test tool for Web applications -- so don't.
8. Your own cache (especially distributed ones)
Before the NoSQL buzz, rolling your own cache was a great way to get your boss to fund your R&D so that you could launch your own startup and hopefully get acquired by an industry Goliath before retiring -- either "in place" or to Tahiti. However, if you start a new project today, you probably won't get the startup cash. VCs don't like to fund last year's trends.
That's OK -- you don't need to create your own cache. Sure, it isn't technically difficult to write your own, but it is oh so easy to make one that kills the database when starting up under load, leaks memory, or causes threading problems. At most you might need to write your own custom cache loader or cache store for one of the existing cache tools, such as Gemfire, Terracotta, Infinispan, and Coherence. Best of all, some of them are open source, so you can fix them if you must.
7. Your own inventory system
The same concept guides inventory management and your public library's operations, minus the part where it dreads e-books. You may need to customize them a bit, but several general inventory management systems are already on the market, such as the open source OneCMDB, IBM's Taddam, and Hewlett-Packard's UCMDB, to name a few.
6. Your own workflow engine
Yes, people still write their own workflow engines. After all, they learned about state machines in school. But since graduation, they haven't bothered to look up the open source Activiti, JBPM, or any of the countless others. Things happen, states happen, you store those, you continue from that point with that state. The problem is solved. We don't need 100 more of these.