Balancing Complexity and Flexibility: Why Not Use the Best?
I really dislike complexity—okay, I hate it. I realize, though, at times things naturally are complex. They just are. So what I really hate then is complexity when it doesn’t have to be there. I especially hate masking complexity with the excuse that it offers “flexibility.”
All too often I see developers fall into this trap. We mistake complexity for what we think is flexibility, but it’s really not. The customization and coding we do to make things work the way we want place an undue burden on us. Software like this is not a real solution but rather a framework for you to code and maintain in order to provide a real solution. That would be more acceptable if two conditions were met: first that the complexity and coding is necessary, meaning it can’t be handled by the solution itself and second that it is described and marketed as a framework for your development.
Let me give you an example of what I mean.
Converting from CA Endevor to ISPW
Here at Compuware we converted from CA Endevor to ISPW for our Source Code Management (SCM). We, like all Endevor shops, had a lot of custom processors that we had to build to get things to work. There was this whole infrastructure of processors, really outside of the product, and every time something had to move from one level to another, we needed to first write and then maintain that processor for the long term. The managing of these processors became time consuming and proved to be a roadblock when we needed to make a change. In effect, we coded the solution ourselves, leveraging the framework of Endevor. I don’t think we ever thought of it that way, but that’s what it was.
When we switched to ISPW it really opened our eyes to the unnecessary complexity we’d been living with using Endevor. When we converted to ISPW we were able to eliminate the processors for “Move” and “Delete,” and that was just a start. They were replaced by a simple panel where we went down to each type in the applications and basically filled a column with a code to say what we wanted to do. It was that easy.
Going forward we have a clear understanding of how things are being handled—it’s right in front of us. If we need to make a change it’s a simple matter of updating the panel, and anyone can quickly understand this and make a change. This is the example of a flexible solution that does the hard work for you. We are spending much less time in administration and making changes don’t have the delay they used to.
As a Product Manager looking at solutions, I work really hard to provide flexibility where it is needed. And, importantly, I strive to provide true flexibility, like avoiding dumping coding on those who install and maintain the product. Sometimes things like SCM products are naturally complex, but that complexity should be handled out of the view and participation of the user. The goal of a product should be what we’ve termed “elegant simplicity”: a simple, intuitive and natural way to accomplish what needs to done.
Read my other posts in the “Why Not Use the Best?” blog series
- Data Access: Why Not Use the Best?
- Exit Strategies: Why Not Use the Best?
- Compile Skeletons: Why Not Use the Best?
- Impact Analysis: Why Not Use the Best?
- Waterfall to Agile SCM Conversion: Why Not Use the Best?
Latest posts by Mark Schettenhelm (see all)
- Planning Better for Failure: How Mainframe Error Messages Impact CX - December 12, 2017
- What Makes ISPF So Scary? Five Reasons to Banish the ‘Green Screen’ - October 31, 2017
- Ten Cross-platform and Mainframe DevOps Tools You Need Today - August 7, 2017