Is CAB complex? And if so, Why?
Recently, there have been several posts critical of CABs complexity. Personally I have no issue with being critical of the complexity of CAB. First off, it’s your right to give your opinion. Second, CAB is complex! Whether that complexity is warranted or not is open to debate. One of the reasons we built the Smart Client Software Factory was to make CAB more approachable. The way SCSF does this is through automated guidiance (recipes) that help you build some of the core CAB components such as a Shell, Modules, Views, etc. Without SCSF, building on CAB is significantly more difficult (though not impossible).
Most of our customers have said that the learning curve is significantly less when you use SCSF. You don’t start off with a clean slate, but with a working application. Furthermore the guidance packages provide assistance as you further develop out your application. Now is it an end all solution? NO, but it certainly makes working with CAB dramatically easier, at least per our customers’ have told us.
As far as the complexity of CAB itself, let me first clarify one thing. SCSF / CAB is by no means meant to replace standard Windows application development. On the contrary, CAB was built to address some very specific requirements based on very real applications. These include the Microsoft Customer Care Framework and the Integrated Dell Desktop. The requirements of these apps are:
- Ability to support multiple teams developing different parts (modules) in isolation.
- Ability to extend existing and add new modules to the application without recompilation.
- Loosely coupled components that can share data and interact with one another as well as the UI (i.e. populate menus, toolbars, and status bars)
- Standardized and extensible layouts.
- Pluggable UI components.
- Pluggable application services that can be globally accessable such as Authorization and Authentication.
- Separation of UI, Business and Infrastructure concerns.
- UI Testability.
- Reducation of repetitive coding tasks.
- Simplified deployment.
CAB provides a standardized, repeatable approach to addressing all of these concerns. However these benefits come at a cost one of which is complexity. That being said the compexity CAB introduces is far less than the complexity one would face if they were to build the same functionality from scratch. Now if you don’t need this functionality within your app then CAB can certainly be overkill and can make your life far more difficult than building a simple windows application. The other side to this is that using CAB is not necessarily an ‘all or nothing’ game. For example if you wanted to, you could have one Shell project and only use CAB for the UI capabilities such as Workspaces and Smart Parts. CAB does not require you to define WorkItems, Services, etc.
As to our implementation of CAB and using ObjectBuilder, etc, it gets the job done. Now could we have done better? I am sure we could have. Is CAB perfect? No. Did we say it was perfect? No. We do know that many of our top tier customers love CAB, and are using it in some very large mission critical applications. The adoption of CAB continues and with SCSF, developing with CAB is more palatable. This is what we hear from customers.
Just the other week I spoke with a customer about a large scale migration they performed to CAB. One benefit they found was a significant reduction in the original codebase once they got to CAB. The other was the common taxonomy CAB introduced within their orgranization which helped bring all the developers and architects on the same page. Once the basic CAB concepts were absorbed they reached a phenonmenal level of efficiency. I can’t tell you who the customer is, but you will have to take my word for it.
When we set off to develop WCSF we had the aim of providing a more simplified model (based on customer feedback). In developing CWAB we deliberately dropped a lot of functionality that had been present in CAB. Since then our approach in WCSF has been to add features solely based on what our customers are asking for. We’ve been very transparent about both our plans and the actual development and will continue to do so. For our last release of SCSF we had community drops every two weeks which we are planning for the next version of WCSF as well.
patterns and practices:
I’ve heard a lot of comments about patterns and practices, how we don’t care abut customers, are not connected, etc. As many of you know I only recently joined patterns and practices as the Client UIX Product Planner. What I can tell you is that connecting with customers is priority number one.
1. In the first month alone, I have engaged with 10+ customers. In at least 4 of these cases, this was customers who came on site for several days and engaged 1 on 1 with the team. This included our product planners, program managers, architects, and developers. The customer list is a mix bag of both those who have already built on our deliverables as well as those who are looking to use them in future projects. They sizes of these orgs varies from small ISVs to medium and large enterprises.
2. All of our our product plans are reviewed by an advisory board comprised of industry professionals that are actually using Entlib, WSSF, WCSF and SCSF within their organizations.
3. We regularly gather customer feedback through Codeplex WorkItems, Surveys (we recently launched an factory surveys), blogs (all the product planners and much of the p&p team have blogs), web casts, and direct emails. Personally I have posted several times in the last month alone asking both implicitly and explicitly, ‘What do you want us to build?’.
4. We recently worked with the community to launch a set of contrib sites for providing community extensions which ultimately will aid our customers.
This is not to say that we are perfect and that there aren’t areas we can improve. We can. We are always open to your suggestions, so if you have any for WCSF / SCSF, please contact me directly.