Blank Checks

Design by Freepik

The idea here is that someone signs a blank check, not knowing what the final amount will be. It can come back to sting the person.

Now how is this relevant to a development project? This is applied from the perspective that if someone makes a short sighted design decision that makes sense from the perspective of a single stage in a project’s lifecycle, it can come back later to sting the organization. A short term gain can be at the expense of an inordinate amount of recurring activity later.

For example, a “hack” patch is made to a free open source software (FOSS) package to implement a feature. This is fine until the package is upgraded and the patch doesn’t work. Someone has to do the work again. What happens if no one understands what the patch did? What happens if the patch was buried with the original recipe and hence gets discarded when the new version is imported into the project?

That original design decision led to the signing of a blank check.

Another perhaps more common case is an upstream design process (e.g. mechanical or PCB design) makes decisions that software team suffer from. Or perhaps the software team makes decisions that the test and documentation teams have to live with.

Using custom drivers could be an example here. After each major upgrade, the custom drivers have to be revisited. The same could be said of custom board support hacks to the kernel. These have to be revisited with each kernel upgrade. Someone rushes a project to completion without regard for recurring maintenance updates and system upgrades down the road.

A flip side to this is “one-of” customization activities. We expect a feature to benefit multiple customers and lead to recurring revenue. That way we can amortize it over many sales and many releases. Hopefully the recurring revenue exceeds the costs of recurring activity. But this is NOT so for a one-of customization for a specific sale. You cannot amortize that one-of cost. It has to be entirely covered by that sale. Who else wants to pay for something that only the one customer uses? The project never ends with fulfillment of that sale. That customer won ‘t like it when a standard upgrade results in loss of that customization. If there is a maintenance obligation associated with that sale and customization, then you just signed a blank check.