Solution Framework Decision: Productivity Win or Tech Debt?

Software framework selection represents a critical technological pivot in an organization. Whether a framework relates to data, server-side code or presentational layer, the implications of adoption will be long-lasting and can represent great productivity wins or years of tech debt.

Decisions about frameworks involve considerations of current development trends as well as finding if there is a philosophical fit between your own organization and products and the framework. However, there are some universal calculations that can be worth doing.

Productivity Wins.

Productivity is the most alluring part of frameworks, which invariably have efficient ways of achieving specific outcomes. Trying to do the wrong thing in the wrong framework can likewise impose a burden of inefficiency. If this part of the calculation is not indicative of a win, it is unlikely that the framework is a good idea from any perspective.

Best Practice – Collective Wisdom.

The best practice side can still offer a vital win. Data security, robustness in all situations and even code performance under load may end up in a better place because of the knowledge and experience that builds up around community solutions.

Solution Complexity.

The long-term calculus is a much more intriguing one, and one that preys on the minds of technologically driven decision makers. Rich Hickey has been a strong advocate of “simplicity” as distinct from “easy”. Frameworks often sell themselves by making it quick and easy for a developer to create something, but whether the resulting code is technically “simple” is a more difficult question; and in some cases, it absolutely will not be. The calculation splits into two scenarios:

1.    My framework stays current. If the framework stays current, then so long as we don’t write in ways antagonistic to it (for example by overriding functionality and making it harder to upgrade), we can view our complexity in terms of: Solution Complexity = Project Code Complexity. New developers can understand the underlying framework infrastructure because it is still standard, and the project will only need its own code modifying, not the framework.

2.    My framework becomes legacy. If the framework becomes legacy, and assuming it is open-sourced (the best case and not guaranteed), then our solution complexity becomes a sum of the framework’s complexity and the project code complexity, i.e.: Solution Complexity = Project Code Complexity + Framework Code Complexity.  This is, of course, a worrying end-position, and one which at least subconsciously plays into the thoughts of technical decision makers.

Closing Thoughts | Take Aways.

·      There is an assumption that it is safer to use small and simple frameworks, rather than ones bringing more functionality, because of that resulting equation should your organization become the main contributor to the framework. However there is a mistake in this thinking. A framework needs only to be of a relatively small complexity before there is no way your organization will ever bite off the task of supporting it.

·      Developers who write application code tend to be very different to those who make frameworks. To make that more concrete, consider that any library upon which your solution relies, which is of sufficient complexity that your team can’t look after it, and which doesn’t have a viable alternative, has the same impact should it fall into legacy as an entire ecosystem.

·      Therefore, it makes more sense judge the framework on its benefits and its level of adoption and support, not on an abstract notion of whether you might theoretically be able to understand it enough to fix and update it.