Building abstraction layers into your application is a good thing, right? By the way, building only enough software to deliver to requirements provides the highest value. Also, make sure that when you add functionality to your application, it doesn’t require a code change. But don’t try to predict the future uses of your application because you cannot know what they will really be.
The above paragraph sufficiently confuses these seemingly wise and contradictory design statements. While you have undoubtedly heard these ideas expressed as best practice, how do they relate to each other? Are they contradictory? Can you successfully plan for the future and be a minimalist at the same time?
Sometimes.
Planning extension points into your applications can be a double edged sword. If you are true to the idea of building minimal features to get your product shipped, then how do provide logical ways for future functionality to be added.
Use Preexisting Frameworks
The .Net CLR itself is a primarily a wrapper on the pre-existing functionality available in Windows. Taking it up a level, something like Log4Net provides even more functionality with less code. Going still higher in abstraction levels is nHibernate, and at the complete application or backbone level we have things like Eclipse, BizTalk, Share Point, TIBO, and Dot Net Nuke.
All of the aforementioned systems are extensible in some way. These frameworks are there as enabling technologies so that you get to write less code. Using these and other pre-existing solutions to provide the big abstractions in your solutions is a reasonable way to go and may help to effectively focus your IT strategy.
Know the Business You’re In
Yes, we write software, but that is rarely the business we are in. Most developers are in the business of making something other than products for other software developers, therefore we must know about those domains as well. We may write software for healthcare, financial services, AOL, your mom, or the real estate industry, and in all cases we need to understand our users. Having a genuine familiarity with users helps guide predications about where an application will likely need extension points.
For example, if I am building another CRM for my sales staff, the first release may not include support for tracking spouse and kid names for clients, but I can reasonably predict (because I know my VP of sales pretty well) that he will want that in a subsequent release. Knowing this helps me reasonably predict a desired extension point in my application for being able to model and persist a customer with a family. (Lame example)
The Rule of Two
If you are going to provide an abstraction layer as an extension point in your application for further enhancements, provide at least 2 implementations in your first release. Even if you are just mocking one in your unit tests it is a valuable thing to do. Not only do you get to experience your software as a future customer will, but you are providing a nice example to your customer. The fact that you are actually doing 2 implementations will often drive positive changes to your design.
Technorati tags: Architecture, Software Design, Software Development