Developer Lessons Learned: Flexibility is a Bad Word?

Body

The tree control found in IBM Asset Configuration Manager (ACM) used to display hierarchical data has changed as of version 7.5. The new control is far less flexible than it used to be. Why?

Please allow me to share some lessons learned with fellow developers and application designers.  For many years (I fell in love with programming in 1979), the buzzwords "flexible" and "reusable" been heavily emphasized when it comes to program code and the development of components such as the ACM tree control. The version created prior to ACM 7.5 was called the VTree control (the new version is called the TableTree control), and was created with flexibility and reusability in mind.  There is a tradeoff when creating something this way, however.  It becomes more complex.  The thought at the time of its creation was that software engineers deal with complex things all of the time.  It is their job, after all.  However, the software world is changing.  With products like ACM, many many hands may touch the code.  From the different developers who may be involved in the creation of each version of ACM, to the developers fixing defects post release, to the Global Business Services developers doing custom work. These days, even third party companies may wind up working with the code.

Analysis of where a group of ACM defects originated showed that the VTree was often involved somehow.  Further investigation revealed that developers making tangentially related changes would make some small change to the code used to display the tree as part of their effort, without realizing that they were creating an issue.  After all, why surmount the component's learning curve when your change is simple and barely related to the tree control itself?  In an environment where so many hands may touch a product's code over the timeline of its existence, highly complex components are vulnerable to becoming a liability.  With so many people involved, any section of code that has a learning curve can turn into a source of defects.

I believe that the takeaway from this should be that, code and components should be as simple externally as possible, with their complexity being encapsulated.  The old VTree control could basically display anything.  It required some code to be written for whatever appeared in it, but it wasn't even limited to just being a tree control.  In contrast, the new TableTree control requires very little development effort.  It is basically just a few lines of xml in the application presentation file.  The only code required is if there is an icon added and something has to happen when it is clicked.  All of the tree functionality is internalized with the potential to be overridden if some special behavior is required. The flexibility of the old control is lost, but the tradeoff is that we also lose most of the vulnerability to breaking the way that the control itself displays things.  This way we reduce the expense of fixing defects. When defects do appear, they can be properly seen as a flaw in a custom behavior created for the control, rather than having the component itself seem flawed.

So, is "flexibility" a bad word?  My answer is yes if it exposes the myriad developers that will encounter it to unnecessary complexity.