Dragons in the Algorithm
Adventures in Programming
by Michael Chermside

Culture of Reuse - Part 3: The Case for Reuse

Part 3 of a 4-part essay

In the previous essay in this series I pointed out that Capital One is good good at innovation, but isn't particularly good at reuse... so what? Everyone has strengths and weaknesses, maybe this isn't such a big deal! If the cost of being good at innovating is that we build a few extra frameworks, maybe that isn't so bad. I would argue that it is so bad -- that failing to reuse things is such a serious problem on many levels that we ought to change our culture so it begins to value reuse (hopefully without losing our strengths in innovation.)

The first and most obvious problem with not doing a good job of reuse is that we invest time in developing multiple solutions. If we create 3 different systems for secure file upload we have spend 3x as much time and money. We missed out on the opportunity to get a great deal of other work done with that effort.

The second (related) problem is that of managing bugs. In 2017, Equifax failed to apply patches to the Apache Struts library, causing them to leak data on about 150 million customers: we don't want to run a similar risk ourselves. The more different codebases we have implementing the same functionality, the more "surface area" we have of code that needs to be debugged and maintained.

A third problem is incomplete functionality. If we build three systems for automating file transfers between systems, one may be architected to run efficiently in the cloud, another may have excellent alerting and retry capabilities for failed transfers, while a third may have a highly flexible trigger system based on a flexible time schedule and/or when files are generated on the source system. Unfortunately, if you want two or more of these features you are out of luck. If we had reused the original system, perhaps we could have built just one file transfer tool that had all three capabilities.

A fourth problem with poor reuse is that systems can be incompatible. three years ago, Capital One had completely different systems for performing money movement depending on whether it was a branch-bank account, a direct (online) bank account, or a credit card. Each had a perfectly servicable system for payments, but because they were three different systems, you couldn't easily do transfers between the three back-ends. Which, of course, is something our customers wanted to do quite frequently. It required a couple of years of effort to build our "universal money movement" system, which is designed to be compatible with all of these.

Finally, a fifth problem relates to the paradox of choice. Just as consumers have a harder time picking out a can of beans in the store if there are 5 different brands with varying prices, sizes, and special qualities, so a programming team which must choose between multiple widely-used frameworks (Chassis, Spring Boot, Lambda Services, etc) for their project must expend effort deciding what is the best choice.

Is five reasons enough? Reuse is an incredibly important part of being an effective software development organization. Just as no modern tech firm would want to have a policy of avoiding open source (yet ANOTHER form of reuse), no one should run a tech company with a culture that doesn't encourage reuse.

[Back to part 2] [See the conclusion in part 4...]

Posted Wed 30 May 2018 by mcherm in Software Development