Desktop Subset
In designing the .NET Compact Framework, we knew that we needed to end up with a compatible subset of the desktop .NET Framework that met developers' needs. How to define this subset was the subject of significant debate. Was it best to take the desktop .NET Framework and start removing the pieces that we did not need, or should we design from the ground up starting from nothing and adding only what was proven necessary? Unable to resolve this philosophical question, we resolved to do both and see which approach proved the more workable. This was a costly effort both in terms of time and resources, but in the end I believe it was the only way to solve this debate. A top-down approach allowed us to identify the key areas of richness we wanted to support, and a bottom-up approach gave us a very good idea of how small our minimal implementation could be and what our size and performance budget was to add features. (For the record, I was on the losing side of the debate, having originally advocated a top-down approach to building the programming libraries. The top-down model proved useful in understanding what we wanted to build but could not give us the performance we needed. The bottom-up approach was the only way to ensure we achieved this goal.) In the end the choice became very clear. The only way to achieve maximum performance and meet our size goals was to start from scratch and build from the ground up, adding each type, class, method, or property only as needed and justified. Even through this process we ended up with more framework than most people predicted in the outset, but the result was a clean and optimized solution. I believe there is a general lesson to be learned here: When designing a subset of a desktop or server framework, component, or application, it can be useful to early prototype by taking the desktop or server component and removing pieces to get a sense of what you want; however, when it comes to actual implementation, building from the bottom up will give you a much cleaner and well-understood implementation. Think top down, build bottom up, and measure at every step of the way. |