On Complexity In Developing Frameworks

By Peter Bromberg

We as developers often get "thrown into" an environment where an existing framework is already in the process of development. We therefore do not have the luxury of suggesting changes, and we are expected to embrace the codebase as is and work with it. So far, well and good.

But, there can be problems. Sometimes the underlying assumptions about interfaces and design patterns can change on the fly. Engineering might be relegated to being done on an ad-hoc basis. This invariably engenders major refactoring which can consume many man-hours of programming time. I've seen this dozens of times, and it always increases the cost of a project.

I have often said that you can make a complex framework "elegant" but, at the end of the day, it still remains complex.  I once worked on a major healthcare provider's .NET framework as a contractor. The manager there, who was a lot smarter than many believed, said some things that I will never forget. One of them was that he used to walk around the office saying "Simplify, simplify, simplify". He was right!  

Unless there is a solid infrastructure that has been carefully planned in advance, any framework is subject to the abuse of "add-on" functionality by developers who, faced with a problem, decide to "cobble together" some sort of "fix" that renders the original design (which may very well have likely been deficient) either inoperable, or more difficult to work with. This is the kind of "cobble together" development paradigm that creates monster complex frameworks that you will regret later!

I've seen code engineered by well-intentioned developers that turns into what I call "churn code" - one method call has a stack track that is so long and convoluted as to be wholly unintelligible - not to mention that fact that the .NET compiler is jumping through hoops making recursive call upon call to do what ordinarily should be the simplest of operations.

How to Fix it:

Bill Wagner, in his remarkable book, "Effective C# - 50 Specific Ways to Improve Your C#", gives us a strong clue: Use smaller methods. If you have to use #region tags in your classes, there's a good chance they're already too big! I detest regions and I never use them!

Another key design approach is to engineer simple, testable units of work that can be enhanced and improved later -- as the framework evolves. In other words, don't do the "Grand Design" from the get-go. That can be a real deal killer!  Instead, write classes and methods that encapsulate only the very basics, and engineer them in a way so that they can be extended as development proceeds.

On Complexity In Developing Frameworks  (548 Views)