The Pit of Flexibility

As software creators, our passion (and livelihood) is to translate some human want or problem into CPU instructions. Often as the application matures and expands, regardless of architecture, there is a significant burden placed on the trainers and support staff as they work through inquiries by the user community. When an inquiry is strange enough, it can finally make it back to the developers to handle (which will rank nearly as fun as writing documentation). Sometimes your users will continue to demand additional options from the application, and as those are added, so does your support/training efforts.

How Did We Fall

Our applications usually start from a simple problem (something is costing someone money), but finish as masterpieces of problem solving. There are many natural complicating factors that go into this finished solution, the principal among them being users require various ways of getting the answers they’re looking for. Additionally, as a programmer, I rarely want to work on a problem that isn’t difficult. All of these forces contribute to taking a once simple solution and creating a Pit of Flexibility.

The Cost of Flexibility

Martin Fowler had this comment about flexibility in software:

The cost of flexibility is complexity. Every time you put extra stuff into your code to make it more flexible, you are usually adding more complexity.

This complexity will directly affect your users… which in turn will load down your support staff. You may have the brightest support staff, but problem solving a batch calculation system is a difficult and long business even for a few elements. Once the support staff is spent, inquiries will be sitting on the your door as the developer.

Often these problems aren’t bugs, they’re just buried complexity. Each element on even simple calculations can product a BigO effect on the final complexity of the answer. On applications written by different developers or teams, this problem solving can be compounded even further, taking the style and approach of each developer into account. So how do we as programmers shift these efforts back where they belong, so we can catchup on the latest 360 FPS find something more productive to do?

Jumping off the Treadmill

The way off this treadmill is simple: let the people upstream see what your application does, let them be able to analyze how your application solves the problem. Consider Wikipedia’s entry on problem solving, specifically the characteristics of difficult problems:

• Intransparency (lack of clarity of the situation)
  • commencement opacity
  • continuation opacity
• Polytely (multiple goals)
  • inexpressiveness
  • opposition
  • transience
• Complexity (large numbers of items, interrelations, and decisions)
  • enumerability
  • connectivity (hierarchy relation, communication relation, allocation relation)
  • heterogeneity
• Dynamics (time considerations)
  • temporal constraints
  • temporal sensitivity
  • phase effects
  • dynamic unpredictability

The next time my application is stuck in the Pit of Flexibility, and I cannot reduce its flexibility, I’ll be building time into my estimates for additional interfaces that provide:

• Transparency: context of the solution and problem
• Singularity: ability to find a specific example of a problem or work backwards from a solution
• Simplicity: capability to filter elements of a solution, while offering the completeness of the full answer