Flexibility, Technical Debt, and Process Debt
- December 3, 2010
- 2 Comments
This article is about software design, and makes the case that flexibility for flexibility sake should never be your goal. There is a very delicate balance between design and implementation in order to provide both usability and capability when it comes to software. Flexibility is often held up as a axiom, but flexibility should be provided only to the extend that it is actually needed by the end user.
I’d put it slightly different: flexibility should be provided to the extent that it is either less work, or actually providing value to the end user. In that order. If the absence of doing something yields flexibility, that’s good. But if you design your software to solve hypothetical situations that have yet to manifest, you run a real risk of overdesign (and over-engineering).
Keith goes on to document a set of rules to keep software simple and maintainable, including removing outdated functionality. You could sum these up as minimizing technical debt (or in BPM, process debt). The less debt you incur, the more maintainable (and less costly) your code base will be going forward. The more debt you retire, the better, generally speaking (but, there are trade-offs to retiring debt).
The key insight:
What I am trying to say here is that our normal intuition about the value of designing up front is wrong most of the time when it comes to software because it is not like a physical production process.
So true. Great read, I recommend anyone technical read the whole article. If you’re not technical, you might want to read it anyway – it will give you insight into how much the flexibility ideas of your technical staff are costing you.