Patform Requirements require balance

The Developer’s Dilemma – Session 3 – Platforms and The Creep

Session 3 – Platforms and Creep – Maintaining scope in the face of business reality

As discussed in previous entries in this series, build versus buy hinges on a concept of technical debt. More importantly, the question of where you want that debt to be burdened. To this point we have focused on what can be considered “hard debt”. This is technical debt that can be repaid in the normal course of skills growth. Developers always want to push the boundaries of their skills and try new things. In theory, this should lead to an increase in debt repayment of these “hard debts” as your platform matures. There is another type of debt to consider in the build vs buy decision, and that is the idea of “soft debt”.

Soft debt is the technical debt that comes from deep experience in the business domain. The more complex or heavily regulated the business model, the more this type of debt occurs. Soft debt cannot be repaid so easily or quickly as hard debt. Think of times when someone who was at your organization left after many years. The knowledge they took with them of the business, the real, inner workings of it, is the “soft debt”. You cannot repay it with a class in a specific skill or by simply “doing the job”. It is built on meaningful experiences and “time on target” and there is no way to accelerate it.

Soft debt also deeply influences your potential hard debt. Rigid requirements in the business domain can result in complex and difficult solutions, creating more hard debt. This is probably the place where in-house development starts to fall apart the most. When gathering the solution requirements to design a solution, application, or platform, it is imperative that the solution meets the actual requirements, not just the perceived requirements. What do we mean by that?

Dillbert cartoon about requirements

Perceived Requirements

“Perceived requirements” is shorthand for “what you think the solution needs to do”. This is the most common side effect of the “I can totally build that” response. It almost always results in two horrible conditions for everyone involved: scope creep and feature misses.

Scope creep

Scope creep is the phenomena by which features are added into a project that causes the overall scope of the project to expand infinitely. It’s the “Boyle’s Law” of features. It says, until they hit a firm barrier, features will continue to expand. Without rigorous process and development methodologies, the inevitability of scope creep is all but impossible to root out. It requires strong structure, roadmaps, mile-stones, and a willingness to push back on the business. This is not a technical problem, and as such none of these processes are trivial to enact. They require diligence and strong leadership at all levels of the organization to ensure success.

Feature Misses

Feature misses happen when there is a requirement for something (real or perceived), and the delivered feature misses the mark. This could be an incomplete or under-developed feature. It “almost” met the goal. Worse, it could be a completely wasted feature. Now you have spent technical capital building a feature, which also increases your technical debt, and it isn’t even required. This happens frequently when there is a failure to perform complete business requirements gathering before a project commences. It is also extremely common in product companies, where there is a weak or non-existent product management and feedback cycle. In both cases the result is software that doesn’t match the market, or the need, and is invariably left on the shelf.

By integrating against a platform versus attempting to build the entirety of the solution from scratch, the scope creep and feature miss phenomena can be reduced. The features of the platform are what they are, and while they can be added and changed over time, that functionality depends on the vendor. Any platform you will use absolutely includes numerous functions that were put forth by its customers. It also allows customers to build additional functions that are “out of scope” for the platform. This offers you the baseline guarantee of a platform feature set that ensures a more rigid adherence to the needs of the business. It also allows you to “bolt on” additional features, either through integration or custom development, so that missing features can be added in seamlessly.

Actual Requirements

Building a solution from scratch is an immense undertaking and there are many steps along the road. I love this excellent diagram by Justin Baker at the Realtime API Hub3:

Platform Building Steps

https://realtimeapi.io/the-6-step-build-vs-buy-model-for-developers/

Intriguingly, it is also a viable diagram of the solution building process, not just the decision process. All good projects start with identifying the business requirements and the scope of the project. Unfortunately, not all projects are good projects. What’s more, many requirements and sticking points can be missed. Domain expertise is critical in identifying and mitigating risk and delivering solutions that can serve the end-goal effectively. This is the “soft debt” load that underpins a lot of requirements needs. It is also where many projects fail to launch, as they have missed the mark right out of the gates.

So What’s the Right Answer?

One of the strongest arguments for using a platform in any scenario is that the platform builder has already performed the first 4 steps of the discovery process. To build any platform, you need to understand the needs, the market, the features, the regulations, and create and build multiple possible options for the platform. A platform offloads and services the soft debt load so that you can focus on the specific hard debt that is most applicable to your own systems.

This is not to say that there is no discovery element with evaluating and implementing a platform. There is always due diligence on both sides to ensure the right fit of features, and mitigation of possible risks. The fundamental decision is whether the work of identification and mitigation internally is worth the level of effort and manpower/time required. More so when you think of the life-span of a project that will require frequent adjustment and updates. It has to keep pace with the customer demand and regulatory requirements in a rapidly evolving marketplace.

This is also the type of work that the majority of true developers are ill suited for, because it requires a lot of external conversations and interactions. This is usually where you need to bring a project team and other resources to bear. That can be a show-stopper for a lot of organizations because of the extra manpower involved. It will also greatly expose the need to find resources with the right domain expertise (soft debt). When engaging with a platform provider, one unique element they bring to the table is that they often have this expertise in house. They can help you make more comprehensive discovery simpler by offloading much of it through a service engagement.

An Outcomes Focused Platform

There are arguments for and against building something 100% in house, and there is never one right answer. The key factor is the ability to collect, maintain, and adjust business and feature requirements as your solution takes shape. It is a critical consideration to keep in mind that developer productivity is directly correlated to interruptions. Building a solution is a long set of interruptions and planning meetings broken up by short stretches of actually building. This results in the worst feature miss of all, the one where the market is ahead of what you built when you are “done”.

Patform Requirements require balance

A platform accelerates your capabilities by removing one set of features from the consideration process. You will always need to push feature requests to the platform provider, but you do not need to incur more technical debt, hard or soft, to build them. If you decide to build the solution 100% in house, the solution’s feature creep can significantly hamper its own ability to be completed.

Considering the basic features is the most obvious and visible part of the build vs buy decision. Features can also create the longest-lasting impact on your ability to meet new challenges and decisively adjust to change. Building from scratch will give you more control over the final product with the inherent risk of producing something that misses the need. Using a platform solution can significantly increase your ability to meet the need with the tradeoff in control. Ultimately the right answer is that you will always end up with a mix of both options. Your “soft debt” cannot be repaid as quickly as “hard debt”, thus finding the right mix of those in your portfolio is critical.