Brian’s Handy Dandy Rules of Framework Development

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

Another great Wardism

One of the best parts about working with Ward Cunningham when he and I were at patterns & practices is that I’d get to listen to him, and hear these gems of wisdom fairly often. Now that we’re both gone from p&p, I’m reduced to finding these quotes as they are relayed by others. Here is a quote from Ward that really captures the essence of what it means to write great Agile code:

Take all the time you need to make the code as high quality as it can be, but don’t take any time to add functionality that you don’t need at the moment.

bab