I’ve spent most of the past 10 years as a CIO, CTO or Technical Consultant in the Small to Medium Business (SMB) market. This experience has been eye opening and challenged my historical biases toward issues such as in house software development vs. commercial off the shelf (i.e. COTS) solutions. Note, I include well-supported open source products in the latter category.
My biases were that in-house software development was perfectly appropriate (and perhaps even an advantage) for small to medium businesses. After all, the SMB market usually didn’t suffer from the big bureaucratic SDLC that seemed to turn any development project into a 3 year initiative that would be outdated before ever going into production. These organizations could leverage the latest tools, frameworks, and platforms to build whiz-bang applications that would be light years ahead of larger competitors.
While to a certain extent this remains true, my personal experience had led me to a different conclusion. You see, in-house, custom applications are almost always built to a set of specifications that match the requirements of the business at a point in time. While these applications may be state of the art in terms of user interface, programming models, etc. they are rarely designed with the same level of abstraction that is typical of a COTS solution. Why? Economics. There is obviously pressure to include as many features as possible during the development process. Rarely is the time allocated to build in the configuration capabilities to evolve the application seamlessly with dramatic changes in the business.
This kind of capability takes significant investment, the magnitude of which the SMB can rarely afford or justify. Consider the effort required in building a data backed web form. Even with nifty component based frameworks like JSP or Spring+JSTL or Flex, developers are typically binding hardcoded object properties or fields with hand designed UI layouts. Now consider how much more effort is required to build a layer of abstraction that allows forms to be generated or updated based upon meta data changes. Don’t forget the validation and form processing logic!
The justification for a development effort has to consider the revenue and cost savings. Unless the SMB is willing to sell the product to other potential competitors, it is difficult to rationalize the investment required to build a level of abstraction such as this throughout the application. Good COTS must have this level of abstraction as it is the ONLY way they can sell the software to more than one customer.
Since these features are rarely incorporated, the SMB commonly finds itself in a position of weakness after a few curves in business plan. Incremental “quick fixes” become the norm until one day the application starts fighting against the business model. Changes start to feel “awkward”. Data elements appear in contexts that don’t seem to make sense. Code complexity starts to spiral until one day everyone acknowledges that the application is crap and we need to build a new one. Of course, this usually occurs well before the payback is achieved.
This leads to an even greater risk to the SMB: the loss of key employee. Because the SMB development staff is small or even outsourced, the ability to make changes reliably begins to rest in the hands of one or two surviving developers. Not only does this hamstring effectiveness, it also exposes the SMB to a great deal of business risk in the event of a departure, retirement, etc.
When does in-house development make sense for a SMB? Obviously, if the business model is so specific that no COTS exists in the marketplace, the SMB has no choice but to turn to in-house custom development. Another reason for doing in-house development is when a co-founder or key stakeholder is the primary architect and technical resource in the company. In this case, there MAY be a certain degree of confidence that continuity will exist at least through a liquidity event. If the key stakeholder is a passionate technician and keeps the software model in lock step with the inevitable changes in the business model, this strategy may end up becoming a real advantage.
It is always difficult to look at software license costs or maintenance fees and not be tempted to “build it yourself”. However, be careful in considering the risks that this path will surface over the long run.
