Throwing away working code is a programming sin. Slow? Tune it. Cluttered? Refactor it. Obtuse? Document it. The underlying philosophy is that even for a minimally complex application, there is a tremendous amount of business knowledge embedded in every innocuous line, along with the man-years of testing that went into ensuring its current performance, reliability, and general correctness. Technology can be slowly polished, but that business logic is pure gold.
So my team at Conductor is gearing up to rewrite 3 different apps over the next few months. We are in a place where little of our existing code-base is reliable enough to build around, leaving us little choice.
I'm not going to get into what went wrong to get us here, but I am convinced that managing our technological balance sheet will get us out. The realization came to me when I was contemplating Higher One, a company I left 5 years ago, at which the majority of the code I wrote is still running, largely unmodified, in the core of a large financial system. Somehow, what I did back then as a young engineer has survived and produced consistent returns. We spent our time there developing Technologies that solved specific business problems, one after another, and those solutions survive still.
Specifically, I realized that our teams here need to start building "tech assets," which have long-term returns, and to minimize ongoing debt. I want to build technological wealth.
So I'm taking this very literally. We just had a planning meeting where we laid out 6 months of a product redesign, and I took the featureset and mapped that to a set of Assets to build. The Assets are the technological blocks that will be the underpinning of the new product. Big hairy "modules" like SalesForce integration, Authentication, an Ad Trafficking state machine, Activity Auditing, User Management & Permissions, etc. In our UI code, which is a clientside JavaScript app, we're building out JSON-handling frameworks, message dispatching, and rendering layers. The goal of each of these Asset projects is to build a unit of functionality, wrap it in iron-clad unit tests, and build a mini-prototype demonstrating the functionality.
2 months into the project, we'll start working on Features. By that time, we should just be plugging things in and bickering over button corner style. And next time, even if we shift direction rapidly or redesign the UI (like we are now), we should be able to repurpose our core Assets for new features and related products. Effectively, having a stable of reliable assets reduces the actual cost of all future development. That's how I define ROI in software development. Assets yield technological wealth and, hopefully, cold hard cash returns, too.
Posts
