Author/Editor Note: Originally, I thought this post would stand on its own. But after reading it again, it's become apparent to me that this is more of a rant than anything useful. I will be writing follow ups in the future on the OOTB Compromise and vetting OOTB products.
A while ago, my cube-mate at work (we have double-cubes that make us feel all the more disrespected, even though I like my cube-mate) was forced to devote all of his time to building an application with an "out-of-the-box" piece of vendor software. A few months earlier, he had received a bonus for "Technical Innovation," rewarding him for an excellent framework he had written to update the way we retrieved content from our ECM system. I called him "The Innovator." Working on this new application, he became "OOTB" (pronounced ootbah).
Life was difficult for OOTB. The project suffered from massive scope-creep, and the project manager had consistent problems communicating requirements, which often forced OOTB to have to redo pieces of the solution. But the biggest obstacle was the vendor software itself. Its intent was to provide a simple way to organize a Java-driven UI sitting on top of a business process workflow. The workflow processes "cases," which are comprised of faxed documents for various transactions. The basic concept is good: map UI controls to fields and decisions in the underlying workflow. The implementation is sorely lacking. Rather than a WYSIWYG editor, the vendor offers an MMC snap-in with loads of configuration requirements. All of this configuration information is ultimately saved to a "metastore," which manifests in a convoluted Oracle database. In order to make the workflow information available to the MMC snap-in you have to run an import utility; essentially an open file dialog with an "Import" button. To operate on different deployment environments (Dev, Integration Testing, User Acceptance, Production), you have to manipulate (manually) a series of registry keys. I can go on and on. The bottom line is that the end-user functionality of this software is laughable.
OOTB attempted to put a good face on this, but kept running into fundamental design flaws, along with plenty of niggling little problems that drove him nuts. He stopped shaving and started listening to old Slayer albums all the time. He worked long hours attempting to configure user-interface functionality that would have taken him a fraction of the time in ASPX pages. The client continued to throw curve balls, and OOTB kept having to stretch into more ridiculous positions to catch each wild pitch. In the midst of it all, on his own time, he designed a beautiful framework that would have allowed the entire system to be coded and deployed in very little time, compared to the several-hour-long deployments he faced with every design change. I'm pretty sure that the time he took to architect this framework kept him from killing someone.
Months have gone by, and through some magnificent mystery of corporate reorganization, I have become OOTB. I inherited this project. Having heard all of Original OOTB's complaints, I embarked on the project with a "C'mon, it can't be that bad" mentality. Oh it was, and still is, that bad. I've grown a big, bushy beard and spend my days listening to music that would make grandma cry. But, instead of doing something productive, like design a framework for the way this thing should work, I'm writing this post instead.
As a developer, I can't count the number of times I've been asked by my higher-ups to look at a piece of software that is supposed to solve all of our problems with out-of-the-box functionality. This amuses the hell out of me, since I'd be out of a job if these things actually lived up to their marketing. Think of a world where software developers dance on the streets with organ-grinders, where monkeys wear business casual and spend their days pointing and clicking and dragging and dropping. This will never happen, of course. Not because all of us developers would get jobs making the OOTB software, but more because every time I've been asked to evaluate OOTB software, it never does everything we need it to do. Some vendors promise improved functionality in future releases, others ignore you or look at you like you're crazy. Some are smart enough to offer good APIs, others go so far as to sell you their source code. No matter what, good software companies realize that they can never offer everybody everything they want, and good software companies realize that they must, somehow, give the users what they want.
The frustration for management-types that are trying to trim their budget fat is that they don't understand why we need all of these developers around. "Why can't we just buy some software and hire some hourly people to do this instead of paying x developers y salary?" Developers are the first people they target. We're socially awkward, expensive, demanding pains-in-the-company-ass, and it's very, very simple to see us as overhead. Vendors market their software as magic programmer bullets, and with this viewpoint in mind, it's easy to see why management might be quick to sign the purchase agreement.
A good application development team understands that repeated tasks should be consolidated into reusable code. This takes more time up front, but saves gobs of code in the long run. When OOTB software is brought in, there's a pretty nasty honeymoon as well, what with installing, distributing, and learning to use the software. In the end, a well-designed, custom-coded solution is going to serve the enterprise better 100% of the time, because it directly addresses the needs of the business. The OOTB software may make it easier to set up 95% of a solution, but I tell you, that remaining 5% is going to slaughter your bottom line. So, in the end, why do enterprises sink so much money and time into pushing square blocks through round holes?
Probably because OOTB stopped wearing deoderant.
Coming soon: The OOTB Compromise.