Geeks With Blogs
The Unstable Mind of a .Net Developer

This is the second in a series on architecting software solutions where I discuss items that need to be discussed, addressed, resolved, etc. prior to finalizing any system designs..  Part I of this series “Know Your  Audience” can be found here.

One of the easiest pits to fall in when architecting software solutions is to attempt to design the solution to be all things to all people.  Unless the application is incredibly simple and/or has a very narrow use, it is possible to spend substantially more time designing the edge cases of an application than the core application itself.  I have seen instances in which an application became overly complex and difficult to maintain or, quite simply, fail, because too much emphasis was placed on extreme scenarios that could or would occur less than 0.1% of the time.  It is situations like this that make it absolutely necessary to set your limits when architecting a software solution.

 

Setting Your Limits

 

Now, as a software designer/developer, I must admit that I would prefer if i could design solutions that were all things to all people.  But my experience has found that over the past 20 year many times trying to do so is either:

  1. not possible
  2. not desirable
  3. too costly
  4. some or all of the above

With regards to not possible, applying business rules via software is a good example, especially when the user mentions the word “except” as it applies to a specific rule.  If a business rule cannot be expressed in a logical fashion with defined inputs and repeatable results, it is not possible to build that rule into a software solution.  If an HRMS does not track eye color of a companies employees, it is impossible to code a business rule that pays employees with hazel eyes a 3% premium on their paychecks.  I realize this is a somewhat spurious example, but I think you get the point.

As for undesirable, sometimes a “requirement” forces a specific design that is overly complex or has unexpected/unwanted side effects, such as extremely heavy web pages.  Several years ago, I was asked to develop a custom control for a .Net web order entry application that allowed for searching and selecting a medication.  The requirement given was that there were to be no postbacks during the search and selection.  So, I designed a mechanism by which all of the medications were loaded into the page on initial load as javascript objects and used client side calls to implement the functionality.  The control worked exactly as required with this one problem: the page as loaded was about 2MB in size.  Needless to say, page load performance was horrible and ultimately led to a change in the requirements.  Today, with AJAX being integrated into .Net, this requirement would not be a problem, but at the time, the accepted practices of .Net development did not include consideration of AJAX and JSON.

Lastly, sometimes requirements can be so narrowly focused or focused on the edge cases that they become too costly, either from a money perspective, resource perspective or both.  My experience has shown that generally the less volume addressed by a requirement (edge cases), the more significant the cost.  Most application designs should target a 75-90% solution.  That is, applications should be designed to provide functionality that addresses the majority of use cases from volume perspective.  As an example, let’s say that an application’s requirements can be broken down into 20 use cases, of which 12 provide 90% of total volume.  The remaining 8 use cases only comprise 10% of the total volume, but generally have a higher cost and increased complexity.  Any application design should target the 12 higher volume use cases and then possibly include some of the 8 edge cases if cost and complexity can be managed.  If an edge case only provides 2% additional volume but adds significant complexity or costs 40% of the total implementation, consideration must be given to leaving it on the table.

 

Now, as in my previous post, I would caution that these guidelines are by no means an absolute and, sometimes, the client wants what the client wants.  Still, by measuring requirements against complexity, desirability and cost, it is easier and more likely you can deliver better, reliable results on-time and within budget.

 

Now, I plan on continuing my series on Architecting Software Solutions.  In the meantime, I will be presenting my series on Adventures in System.Diagnostics at the St. Louis Day of .Net conference this August 20-21, 2010 at the Ameristar Casino in St. Charles, MO.  You can get more information, including registration details at their website.  Hope to see you there.

 

Ralph Wheaton
Microsoft Certified Technology Specialist
Microsoft Certified Professional Developer

Posted on Friday, July 30, 2010 10:59 AM | Back to top


Comments on this post: Architecting Software Solutions Part II – Setting Your Limits

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © Ralph Wheaton | Powered by: GeeksWithBlogs.net