CodeFutures News & Industry Commentary Blog

CodeFutures sometimes comes access a potential customer that is considering building a code generator for Java persistence rather than buying one. Data access and data integration are probably one of the most common problems facing IT organizations, so it might seem like an idea to build a custom tool.

The debate on buy versus build not happen that often to CodeFutures, perhaps because code generators are non-trivial tools to develop. Perhaps the buy versus build debate is no longer so common because development managers have more control now on the ambitions of their developers? Perhaps budgets are tighter in general? Whatever the reason, I used to see the issue a lot more when I worked in Cape Clear and WestGlobal, perhaps because it's so difficult to make a "one size fits all" integration product.

There are a number of factors that influence the buy versus build decision:

Cost

Building rather than buying removes the cost of license acquisition and ongoing support. In fact, I suspect that lack of budget forces some development groups into the decision to build development tools.

Organizationally, it might be the path of least resistance for a project manager to avoid asking for more budget.

But coding in-house incurs significant costs, and not just in development hours. Perhaps the biggest cost is not directly measurable because it is an opportunity costs. Developers are no longer focused on solving an organization's business problems - they are producing tools that can be used to solve the problems.

Ongoing standards and third party product support is also a key cost factor. Long term maintenance costs are reduced when when using a product because the upgrade costs are spread over multiple users of the product.

Scope

It is usually easier to configure an existing product rather write code. So the scope of the project is reduced because there's less design work, less coding, and less testing.

CodeFutures has developed a very specific strategy around the scope of FireStorm/DAO Architect Edition. Users get the source code, which is well written and documented in Java so is easily understood, and can customize the product to their exact requirements. This is removes one of the key objections to buying and the key benefits of building: having a product that matches your exact requirements.

Risk

Building complex tools in-house carries with it a certain level of risk. Perhaps the biggest risk is the general idiosyncrasies of different third party products. Using a mature packaged product - especially a mass market product - means that the product is already tested in development and deployment across a number of customers, and evolved over time to address any unusual problems arising from these projects.

Reason

Why re-invent the technology wheel? It's not reasonable or logical behavior, but it happens all the time. I think it's because many software developers do not particularly understand or have any interest in the commercial realities of software development. After all, it's intellectually appealing to look at new way of solving the data persistence or data integration problems.

Support

Who are you going to call? More importantly, who are you going to blame? Support is the reason why "vendors" of open source solutions like MySQL and JBoss have a place in the market and why Hibernate will eventually work its way into the mainstream enterprise market.

Time to Market

Faster time to market is the most obvious benefit of using a packaged product that is ready to use immediately. One often overlooked benefit of this is that the gap between requirements gathering and project delivery is much shorter (actually, a benefit of code generation too), which may be critical for the perception of success of a project where the requirements are evolving. Project managers will appreciate this benefit much more than developers - but developers almost always derive a sense of satisfaction from delivering something to end users (actually, yet another benefit of code generation).

Internal Politics

Outsourcing development, especially to India, has become a huge internal political issue in some large US corporations. CodeFutures is both a winner and a loser in this trend. The winning part is that a lot of our customers use code generation as an alternative to oursourcing. Since outsourcing is generally considered to save between 30% and 50% of overall costs, FireStorm/DAO can offer the same level of benefits.

The other way that CodeFutures wins from the outsourcing trend is that team licenses can be used to standardize and control how the data access/data integration tier is produced in the outsourced development center. The Firestorm/DAO architect produces a standard custom template that is optimized for that organization and the outsourced development team uses the template.

But CodeFutures has also lost out on a few enterprise-wide sales due to tool production being a) "offloaded" on a team in India to keep the busy/out of the way or b) underbid on cost in the buy versus build calculation by estimates that could not possibly have taken into account the thousands of hours of development time it takes to produce a tool like FireStorm/DAO.