I’ve run into numerous folks from both the business and technical sides of the world who want flexibility built into software. Developers and managers alike spew out statements like “We want to leave our options open”, “We’ll need to support that one day”, or my favorite “The business doesn’t know what they want”. As developers, we’re constantly faced with pressure to build things faster. Architects and technical gurus ingeniously figure that nothing is faster than making a simple configuration change. “Make it flexible. We don’t want to rewrite anything.” And with that we lay the first brick on the road to the inner-platform effect.

What we really want to do is minimize the cost of change.

This is why agile software practices were created. We want to be able to accommodate change, even late in the development process after significant progress. Some software developers take this far too literally, though. Accommodating change does not mean making every last detail configurable or worse yet, building massively over-architected systems in hopes of supporting yet-to-be-defined requirements.

Think about how long it takes to design and build all of those configuration points. Think about all of the permutations that need to be tested. At the end of the day, how many of those options will even be used? Remember, we’re making our systems and architectures flexible explicitly because we don’t know what we’ll use. By the time this infinitely flexible software is built something new will come along and we’ll realize in horror that we guessed wrong.

Flexibility means you design your software in a loosely coupled manner. Dependencies are injected instead of instantiated inline. You write classes that are 50 lines instead of 5000 lines. The SOLID principles become your best friend. Your software is simple, discoverable and, most importantly, testable. You can make changes swiftly and with confidence that the software is still fit for purpose. To me, this is true flexibility.