The whole basis of my talk at TechEd is that there are some non-technical rules around which creating good frameworks should revolve. Since I mined those rules from my earlier poll on this blog, I thought I should share my results with you. I give you
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
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…
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
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.
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.
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.
Summary
In a nutshell, that’s my talk. I have a lot more detail, a lot more stories, and a lot more to say. If you want to hear it, come see me Friday morning, from 9–10:30 at TechEd :)
See you there,
bab