May 4 2009

Flexible Software

Last weekend I happened to be browsing internet and came across a page listing software quality factors. It listed all the expected desirables –, Testability, Usability, Reliability, Performance, Security. But there was a glaring omission - Flexibility. 

Is it not important enough to be included in that list?

Answer could be Yes and No!

 We could develop software keeping in mind the exact requirements specific to the case and deployment environment, even hard-coding (eeks! I know) and it could work for customer. Of course there will be enhancements and changes in the software over the years, but you could still get away with binding application with rigid environment and requirements. Is that the desired way to develop software? I’ll leave that open to discussion.

Experience suggests that typical custom developed projects would fall in that category.

Product development on the other hand is pretty unforgiving in this department. For most of the products of significant size, it is difficult to imagine consistent environment and client requirements. Customizing product for the client is difficult to maintain, ultimately results in many client applications, and has severe negative impact on time-to –deploy. What would be my wish list in this direction for a product supposed to be deployed in client environment, interacting with upstream and downstream systems? 

  1. Multiple Technology and platform support:  Imagine scenarios where it is not possible to dictate underlying technology /tools to be used in client environment.  You may think JBoss is excellent, but if a bank’s IT department thinks otherwise and prefers Weblogic, one has little choice. If the product developed is JBoss  specific,  it may be costly to change strategy at this point. What if third client doesn’t like Weblogic? Of course a product cannot be certified on all the possible combinations, but it should be flexible enough.
  2. Highly configurable flow:  Although the general flow in a product is expected to be on similar lines, there are bound to be client specific deviations, which may change over time.  How difficult is it to accommodate in the product?
  3. Highly configurable behavior:  There could be so many reasons for this. A new type of tax being levied and client has to incorporate that as well in calculating fees?  How nice would it be if we could just change configuration and it worked.
  4. Flexibility to adjust to client domain model: If the product installation needs to interact with other client systems, there are bound to be variations in client domain model in use by the other systems. It helps to have the capability to cope with this built-in in the product.

 

Of course, not all of these will be required for every product. But in my opinion, there is no doubt that future of products is in writing highly flexible applications.

 

LEAVE A COMMENT

Subscribe Form

Subscribe to Blog