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.
5. Your own e-commerce suite
I left the "e" in "e-commerce" to show how '90s it is. Remember when putting "e" in front of everything made it cool? (At least CNN thought so.) Now they're simply called commerce suites, and there are scores of them: the open source Broadleaf, Magento, Spree, and Zencart; SaaS offerings such as Shopify; and horribly overpriced proprietary monsters like ATG, WebSphere, and WebLogic. If you don't have a traditional stuff-in-a-box business, you may need to customize one of these tools. No matter what you sell online, you will inevitably need to skin the commerce suite and possibly integrate it with your payment processor. But you almost certainly don't need to write one from scratch.
4. Your own reporting engine
I've guilty of rolling my own reporting engine, but in my defense there wasn't anything available at the time. I'd done reporting stuff in Java at several companies because they couldn't get one of the existing ones to do exactly what they wanted. In the end, they dumped to Excel to fudge the numbers and appear to be Sarbox-compliant. So I founded the Apache POI Project (a port of Microsoft's file formats to Java), but joined JBoss before I could write even one line of code on my larger plan for an open source answer to Actuate and Crystal Reports. Meanwhile, JasperReports, BIRT, Pentaho, and others emerged to fill the gap. You should start with one of those.
3. Your own message bus
Last decade, this was the hot thing to write and rewrite. The slow and dusty MQ Series WebSphereMQ was no longer good enough, so we saw entire startups around messaging. JBoss, BEA, and other Java EE vendors each wrote one, then replaced it with another implementation.
You do need to write stuff to queues and have things pick them up. You sometimes need to write on a wall and let everything pick up the same message. That's why there are various options for availability and load balancing from HornetQ, RabbitMQ, ActiveMQ, and many, many more. There are heavy, full-featured options, as well as lightweight but powerful choices. You can most certainly have your needs met without the burden of creating and maintaining this beast yourself.
2. Your own single-sign-on (SSO) implementation
There might still be time to launch a startup here, but your boss should stop your backdoor pilot project and make you use Picketlink, ADFS, OpenAM, Ping Identity, or any of several others. You shouldn't be writing point-to-point SSO, either.
Don't get me wrong: There will be custom work and integration here, as sadly this is an area of poorly implemented standardization. Technology vendors all play lip service to interoperability, but in the end they are thinking of a happy world where you buy their "platform" or "suite" of products and can never leave them or buy anything from anyone else. However, you can save a bundle by picking one overall provider and take a wheel-and-spoke integration approach versus having a hundred point-to-point integration projects or your own probably flawed SSO implementation.
1. Your custom content management system
The world has enough content management systems. They come in many different forms: Some are Drupal-like, some are Interwoven Teamsite-/Adobe CQ-like monsters, and some are SharePoint-like. Some even unite the three approaches (Alfresco, for example). They are all somewhat similar. To quote Tyler Durden: You are not special. Any CMS you implement will turn into one of these three types. Your company most likely does not have content so unique that it won't fit into one of them. At most, you might need to customize or modernize an open source implementation. Making your own CMS is so '90s!
Don't roll your own!
This article, "9 app dev projects you should cancel in 2013," was originally published at InfoWorld.com. Keep up on the latest developments in application development at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.
Copyright © 2012 IDG Communications, Inc.
