Rules for Framework Development
Something i came across while i was developing a framework for one of my clients.
Source : Brian Button's Blog
Brian’s Handy Dandy Rules for Framework Development
- Clients come before frameworks
- Ease of use trumps ease of implementation
- Quality, Quality, Quality
- Be an enabler
- It’s a people problem
1. Clients come before frameworks
This was easily the most commonly heard bit of advice my poll revealed, and it matches up very nicely with my own experiences. The best frameworks are not created, they are mined out of existing code. The worst frameworks seem to have sprung from the twisted imagination of a rogue architect somewhere…
2. Ease of use trumps ease of implementation
As the author of a framework, you need to keep your eye on the ball of making others’ jobs easier. If you ever have to make a tradeoff between changing something to make it easier to implement and changing something to make it easier for your framework clients to use, always choose the latter. Write good documentation, ship your unit tests, and test out your APIs through writing lots of in-house client code. Lots of eyes on the API helps as well
3. Quality, Quality, Quality
Use Test Driven Development on your framework code, and enable framework users to use it on theirs. This means to avoid things like sealed and overzealous use of CAS. ‘Nuff said.
4. Be an enabler
You can’t read people’s minds, so don’t presume to know what their key uses of your framework will be. Allow people to embrace and extend your framework through extension points. Document these extension points, give lots of examples, and create automation to help users with these tasks.
5. It’s a people problem
Building a framework is decidedly not a difficult technical problem. We’ve built these things before, we’ll build them again. It is primarily an issue of balancing people and their conflicting interests. Good architects know this and are adept at balancing these concerns.