Why Your Feedback Is So Important
(Or: How I Learned to Stop Worrying and Love CTPs)
Back in about 2001 I read Kent Beck's Extreme Programming Explained for the first time. It changed my life as a programmer. Of course, Agile is now well-accepted and I'm always a little surprised when I encounter software journeymen* not at least trying to be Agile. But working on framework code that is used by thousands of apps can make some aspects of being Agile quite difficult.
Be simple and refactor
When writing applications I find it very productive to create designs and implementations for what I need at the time and then organically evolve them as necessary (and as my understanding of the problem improves) using refactoring. So if an API I created needs to change it's all cool—I change the API and change any code that uses it.
Breaking changes
But what happens if that API is in use by thousands of applications none of which I am able to change? We face this problem all the time with framework code. We release an API in version x of the framework and then in version x + i we realize that it now isn't quite right…or maybe it's completely wrong for what we want to do with it now.
The problem is not limited to APIs; it also applies to the functionality of the framework. In fact in some respects it is even more problematic to change functionality because an application may build with the new version but then fail at runtime in a way not expected by the developer.
These type of changes are called “breaking changes” because they break existing applications that use the framework. We do sometimes make breaking changes, especially when you would need to re-build the application (or explicitly mess with the linking) to use the new version of the framework. But we really don't like to because we want to make it as frictionless as possible for you to update your apps to use the new version.
What to do?
So how do we give ourselves the best chance of getting the APIs and functionality right before we release it? Which means, of course, how do we give you the best chance of having good APIs and good functionality such that you're not stuck with something that sucks for the lifetime of the product, or, alternatively, have to deal with lots of breaking changes each version?
(In my personal view (this may not reflect the views of my employer ;-)) one thing we need to do is Stop Worrying and be more okay with breaking changes. But even if we do this we will still only make breaking changes when the benefit clearly outweighs the cost.)
That aside, the approach we are taking on the EF team is to iterate a lot before we release. This iteration happens internally as we learn more while develop and test the code. But internal iterations are not enough because we don't think of everything or see everything that YOU, the real app developers, see. That's why we put CTPs and other preview releases out there and ask for your feedback. We really need that feedback. We may not do everything that you suggest, but we listen and think carefully about it all. As an example, we gathered over 50 pages of detailed feedback on EF 4.1 CTP5 and we carefully considered all of it.
If you look at the early versions of Code First compared to what shipped in EF 4.1 you can see that it evolved greatly over time. That evolution happened due to feedback from within the team, from partners at Microsoft, from MVPs, and from you and your use of the CTPs. Code First would not be what it is without your feedback.
So use the CTPs…
So please, please use the CTPs. Tell us what works, what could be better, and what sucks. Right now, the OData and EF teams just released a CTP for Reference Data Caching (aka Offline)—go check it out and tell use what you think. Likewise, if you have comments on the Migrations functionality that Scott Hanselman showed briefly at MIX, then send them our way. (Incidentally, Hanselman's stand-up comedy while coding is worth watching even if you don't care about migrations.)
Also, look for additional future-looking information and CTP announcements on the EF Team Blog and Design Blog. Once we get enums support into a CTP we are going to want to know what you think!
* Feel free to substitute engineer, craftsman, code artist, magic unicorn, programmer, coder, monkey, or whatever you desire. I kind of like journeyman.