REDMOND, WASH. -- Microsoft's Patterns & Practices Summit is lighter on code, and heavier on architectural diagrams, than most conferences. Hosted by the company's Patterns & Practices group, these sessions highlight what the group has deemed the best strategies for architecting .NET applications. Attendees, meanwhile, ask questions, offer feedback and have a bit of a hand in shaping the P&P group's future endeavors.
The latest Patterns & Practices Summit hit the conference center on the Microsoft campus. Each day had its own theme -- architecture, agile, development, software factories and applications. The report that follows focuses on the summit's application architecture day.
Scott Hanselman's First Eight Weeks at Microsoft
The day's keynote presentation had little to do with software patterns and practices. Hanselman spent half an hour chatting about how and why he got hired, by Microsoft with a couple jokes about the Blue Monster thrown in for good measure.
Toward the end, John Lam piggybacked on Hanselman's inclusion of LOLcats in his slide deck to run down to the stage and show off a version of LOLCODE that, believe it or not, actually runs on the Dynamic Language Runtime. (No word yet on whether programmers will actually be able to use this language to build Silverlight 1.1 applications.)
The Future of Patterns & Practices
Rick Maguire provided a look at the main focal points of the Patterns & Practices group and a glimpse at its roadmap for the rest of 2007 and the first half of 2008. As this fits into a larger discussion, it will not be discussed here. Stay tuned for a full-fledged, honest-to-goodness story on future of Microsoft's Patterns and Practices program in the next few days.
Evolving Client Architecture
These days, remarked Billy Hollis, application UIs tend to fall into three categories -- Web clients, smart clients and mobile clients.
Two things add a wrinkle to this paradigm. One is SOA, which, due to its narrower implications for architectural decisions, means that the front end is no longer necessarily tied to the back end. "We enter a world of competition where the best user interface wins," Hollis said.
Ultimately, if architects want to get started with rich applications, then they should ask themselves four questions:
- Are your users captive?
- Is it a large user base?
- Do your users work with rich data?
- Are you starting a new system that needs a long shelf life?
If the answer to the first two questions is "No," and if the answer to the last two questions is "Yes," then a rich application may make sense. The best way to get started is with a local WPF application, Hollis recommended. Not only do these run as a standalone .exe, but they integrate with, and deploy the same way as, WinForms applications.
In any event, Hollis said, "Don't be too ambitious on your first effort."
Freshly Cracked CAB: Managing the MVC Mess
Ward Bell joked that he was the entire patterns and practices group at his employer, IdeaBlade. He then proceeded to demonstrate how to best use the Composite UI Application Block, better known as CAB, for smart client application development.
Using a CAB in an application will benefit end users as much as it will developers, as it brings about consistency from one form to another and allows for repeated content -- that is, the order UI, the customer UI and the sales rep UI can all call back to the same data grid. "This isn't 'Dungeons and Dragons: Go Find the Data," Bell said. "It's cut and paste inheritance."
Applications built using the CAB follow the Model View Presenter framework that Michael Puleio described during the Patterns & Practices Summit's Software Factory day. In this particular case, the model contains business logic, the view contains the display, the input and user actions, and the presenter responds to and updates the model and the view.
There are two types of views, Bell noted. Widget views are those that have visual controls dropped into layouts, whereas layout views hold only other views.
Bell also offered a blanket suggestion for testing -- test less by writing less. What that means, he explained, is that it's senseless to test automated processes like data binding, as that is the equivalent of testing whether the sun will come up. Instead, he said, folks should only test hand-crafted code.
Some comments on software complexity
Hollis returned to deliver the final presentation of the summit. His thoughts on complexity touched nearly every phase of the software development life cycle:
- Navigating the .NET Framework is like going to a giant hardware store for, say, a paintbrush. It takes a long time to find its relative location and just as long to find its exact location -- and when you grab it off the shelf, the instructions make no sense.
- Nor is .NET the unified programming model that Microsoft promised it would be five years ago. Think CSS, Master pages, XAML, TSQL, WCF endpoints and so on, Hollis said, adding, "It's a sign of the times when most of the demos you see from Microsoft show them editing XML in config files.
- Programming methodologies like Agile, Extreme Programming and Test-Driven Development merely "spackle over the problem of complexity," Hollis contended. TDD in particular is indicative of an industry-wide problem, he suggested: "This industry has a substance abuse problem. The substance they abuse is code. They like the physiological effect they get from writing code so much that they won't do anyone else."
- Microsoft is not the only culprit here, Hollis noted. Using Google for search is a mess -- how many spam sites must pop up before one gets to legitimate sites? -- but, because that brings in ad revenue, there is little motivation to fix it, he contended.
Hollis ended his presentation with a six-part Simplicity Manifesto that apply to all software shops, particularly Microsoft.
- Stop adding features. The more bloated an application, the less sense it makes.
- Make Help helpful. Documentation should provide users with answers.
- Fix the bugs. That one's pretty self-explanatory.
- CRUD for free. By providing the that which is necessary to create, read, update and delete information, software vendors can cut in half the amount of time development teams spend on a project.
- Hide the plumbing. This lets programmers focus on what they really need to do.
- Get better names. This one was directed at Microsoft, which has scrapped code names like Avalon and Indigo for Windows Presentation Foundation and Windows Communication Foundation, respectively. Silverlight is a good start, Hollis said.