Limiting Technology To Improve Your Chance of Success

I have been involved, in the past, on projects where technologies were added simply because someone wanted to. There was little or no review of the implications of adding technology at will. The result was demonstrable issues with maintainability, stability and the ability to learn the system. On projects where the senior architects, along with management, kept a tight rein on what is added, the results were simpler projects that were easier to work on, easier to learn for new team members, and easier to maintain and extend. It can be tempting to add new technology, either because it is “cool” or because of some perceived benefit (sometimes based on little or no long-term evidence). However, generally speaking, less is better.

Adding new tools or technologies has a number of implications. While the most obvious is complexity (because it is yet another technology to learn, to integrate and to maintain), there are others that are often overlooked.

Additional complexity also adds to the cost of the product, in different ways. The software itself may be free, but time taken to integrate and maintain, without offsetting benefits, is money spent that could have been spent elsewhere. For commercial software, you have to add the additional cost of the licencing and maintenance. When selecting technology to add to a project, you need to understand the cost (and nothing is ever free) and compare that cost to savings you can (or cannot) expect over the long haul by using it.

Many technologists forget to understand any legal implications for adding new technologies. A careful review of the licence (if possible, by qualified legal counsel) can avoid all sorts of ugly problems in the future. On occasion, a licence can restrict what you can and cannot do with your product. It may open you up to legal action (for example, in potential patent violations). This isn’t typically a problem, but the legal aspects of a new technology’s licence needs to be as carefully reviewed as the technology itself.

Adding additional technology also adds a new dependency on someone else’s release schedule. If you require additional features or changes for your product to work better (or properly), your project can now end up with an outside 3rd party on your critical path.

You also become dependent, quality-wise, on their technology as well, particularly if the technology is a core element of the system. If their quality starts to deteriorate, then so does the quality of your own system. Related to this, your responsiveness to your customers is now dependent on how responsive (or not) the vendor is. If you have selected technology that is core to your system, there is no point in promising 1-hour response time to severity 1 problems if the vendor only promises same-day turn-around on the same severity of issue.

The last dependency is on the future features and direction the product takes. By giving up some control to a 3rd party, you put your product at their mercy, and if they choose to start in a different direction, you may find your product depending on features or functionality that is no longer supported, or not supported as well as you need it to be. In addition to future direction, for commercial products, you are dependent on their future success, and you can find yourself using technology with no company behind it if they go out of business.

Some of these dependencies can be mitigated with open source technologies, if only because you at least can get the source code and take over the care of feeding of it should the community decide to abandon it. This is not always an option for commercial software.

This isn’t to say that adding 3rd party technologies is bad, and that you should build everything in-house. What this means is that, before just adding any technology, some care and due diligence is needed before it is added. Adding technology because it looks “cool”, or because someone claims it can make things faster/better/easier, isn’t good enough. The technology should be evaluated based on its technical claims. The costs associated with it need to be compared to what can be saved. A legal review of the licence should always be conducted to avoid future problems in that area. Adding 3rd party technology often makes sense, but you should confirm it makes sense before committing yourself and your product to it.