"I am endeavoring, ma'am, to construct a mnemonic circuit using stone knives and bearskins." - Mr. Spock, City on the Edge of Forever

What with all the advancements in software development environments, from frameworks such as JAVA,.NET and a host of third party IDEs, libraries and engineering tools available to jump start projects, you'd think it would be easier to create software. Once upon a time a single programmer could write a useful application for some purpose or another (few of you will likely recall the days when we had to write our own text editor to edit the code to create the software, and then an operating system upon which to run it). These days it takes teams of people. That is, of course, if you don't consider writing that mobile phone plug-in a real software application ;). Understandably, the problems we face are getting harder because new tools enable new possibilities that drive the potential reach of enterprise-scale projects -- but it never ceases to amaze me what some people can do with a simple hand-held device.

Based on the often self-fulfilling premise that the available development tools are stone knives and bearskins every project still seems to start out the same way -- with a plan to build the development tools required to develop what's really being developed. I am not talking about fundamentally new tools or technologies, rather components that mirror or come close to existing ones.

My personal belief is that this pattern is motivated by a sociological phenomenon and not a technological one. Many software professionals I have met over the years just don’t seem to like other people's code, and they'll often go to any lengths to avoid looking at it, using it, and maintaining it. After all, I suppose it's a lot more fun to create something new than use someone else's solution, right? Like many in this business, I have plowed through, fixed and refactored my share of digital gob, all the while cursing my predecessor for being so undisciplined, so maybe it's a well-founded trust thing. Whatever the reason, does it make sense to spend man-years in development to define a new language, develop a compiler for it, roll your own IDE, graphical user-interface designer or object-relational mapping tool when your business's core competencies are providing travel reservations? Maybe, but I doubt it. In my experience, 99.99% of the time, it is a fundamental diversion. Even if you can quickly build that technology to help out your development effort, the fact remains that 90% of the costs of building the tools will be spent maintaining them, which is unlikely to be within the core competency of the firm, and certainly not within its business objectives. The costs are never truly estimated from the beginning, and rarely accounted for over time. The irony of all this? As people come and go from projects that span years, everybody gets to spend a lot more time looking at, using and maintaining other people's stuff.

Perhaps this MasterCard moment sums it best:

• That DVD box set of '60s Star Trek re-runs you've been dying to get? 120 dollars.


• A mnemonic memory circuit? 150 million dollars.


• The cost of building your own software development tools? Priceless.