Brian Button from the patterns and practices team gave a session bright and early Friday morning that was great. He covered how to write frameworks. What’s interesting is that he focused on writing frameworks as a non-technical problem since he’s seen too many frameworks that solve the wrong problem very well. J
- Rules for Framework development
- Clients come before frameworks.
- Be sure that you are solving the right problem.
- Quality, quality, quality.
- Be an enabler: You can’t solve every problem, so solve many problems but allow for extensibility points.
- Creating frameworks is a people problem.
Brian stress that it’s impossible to write a good framework without a real application using it. It will end up missing the mark. He suggests, instead, writing several applications and harvest a framework from the common parts of the application. This resonates with me because I believe it’s very difficult to write code that’s intended for reuse. I write code for use, and if it needs to be used elsewhere, I’ll harvest it into a shared library.
Brian was very bold at this Microsoft conference, and I applaud him for this. He stressed automated testing, and he said that here and now there is NO EXCUSE for not writing automated tests. Bravo! Brian contends that functional testing is a waste of a tester’s time. The thought is that testers are too valuable for functional testing that could be covered with automated testing. Testers should be testing the harder things.
Brian shares my frustration about sealed classes in the .Net Framework. He has encountered parts of the framework that are sealed, and when he needs to extend them, he can’t. Sealed classes are hard to write testable code against. He made a good point that I hadn’t thought of before: If you seal a class, you are saying “I can predict the future, and this is all that this class will ever need to do.”
Finally, Brian advocates these in creating a framework.
- Do open planning.
- Practice open prioritization.
- Show visible progress.
- Don’t allow surprises.
Brian recommends
- Resist the urge to create something new. Harvest frameworks from existing applications.
- Encourage quality throughout the project. Lead by example and testers rule!