"Lead or follow, but GET OUT OF THE WAY!"
- plaque on the desk of Ted Turner
I've worked with some really GREAT managers, several of whom had absolutely no software development experience. Some were hardware engineers, some were from marketing, and some were just individuals with relevant domain expertise. Qualities that made them great engineering managers included the ability to quickly grasp the GIST of technical issues, highly-developed BS-detectors, calm in the face of a need for decisions on the basis of limited information, the courage to say "no" to upper management when necessary (and the willingness to fight, to make it stick), intolerance of empty beauracracy, a commitment to the highest (practical) engineering standards, and acceptance of the fact that plans and predictions inevitably CHANGE, incrementally but continuously, sometimes right up until near the very end of a project.
A good engineering manager enjoys getting their hands dirty with the evolving product, and is able to provide constructive feedback like "I was playing with the product yesterday, and I noticed X, Y, and Z", or "How can we design feature A to be better than a similar feature in our competitor's product?" A poor manager takes refuge in a filtered subset of second hand information ABOUT the project, in the form of tidy reports and spreadsheets and charts, and may go to great lengths to avoid commiting to a decision involving actual technical or design issues. Unfortunately, over the course of dozens of projects, at half-a-dozen different companies, really good managers have been in the minority, and were often handicapped (if not initially, then after the first or second reorg.), by having to report to individuals farther up the chain who seemed to consider "management" to be a TITLE instead of an ACTIVITY.
Some managers become obsessed with being recognized as the primary source for all information and decisions on the project. I once walked into a project manager's office, with print outs of bug reports spread out all over her desk, who complained she was being overwhelmed with issues reported by our publisher client. Since I'd recently resolved several issues just by speaking directly with one of the publisher's engineers, I curiously leaned over to look at one of the reports, and she practically THREW HERSELF onto the desk, covering the print outs with her arms, as I sloooowly backed out of the office. On another occassion, a year into a job at the Tokyo offices of a US investment banking firm, I was CC'd on email that revealed that a certain middle manager had been rewording requests for information from upper management, and then rewording my responses, in order to hide the identities of the original email authors and ensure that they remained at the center of all communication. That would have been fine (if a little silly), except that they sometimes misunderstood either the original request or my response, creating confusion and wasting everyone's time. Some dysfunctional managers insist on personally taking charge of presentations, or leading discussions, on issues with which they have only a very superficial understanding, where they hopelessly mangle key technical information, or sidetrack the proceedings onto irrelevant (but more familiar, non-technical) issues.
Managing software engineering is HARD! Even skilled developers who take on a management role quickly lose touch with continually-evolving development technologies and best practices, and must depend on their top engineers for guidance on project decisions. Identifying RELIABLE sources for information from among the development staff is especially difficult for non-technical managers, since it is easy for mediocre developers to fake a convincing level of expertise, while many of the best developers don't bother to cultivate the kind of basic social skills that engender management trust. Some organizations resolve this by splitting management responsibility, giving a "Technical Lead" authority over a project's engineering-related issues (including issues which are not strictly technical, such as "Joe is not performing and needs to be taken off of the project"), while the "Project Manager" takes on a more administrative role, becomming responsible for shepherding issues through the corporate beauracracy so the engineers can focus on... engineering.
I've posted several demo projects to dev. community sites, and I'll continue to update this page as more are completed.
"So, each player gets six cards, except for the dealer, uh, the player on the dealer's right, who, uh, gets seven."
"On the right?"
"Yes. The second card is turned up, except on Tuesdays"
"On Tuesday..."
"Mm-hmm. Oh, look what you got - two jacks! You got a half FizzBin already."
"Heh-heh... I need another jack!"
"No, no, if you got another jack, why you'd have, uh, a shralk."
"A shralk?"
"Yes, you'd be disqualified."
"Oh"
"No, what you need now is either a king and a deuce - except at night, of course, when you'd need a queen and a four"
- Star Trek episode #46, where Kirk and Spock explain WPF
I've spent much of the past year working pretty intensively with WPF (and other technologies), working through all the major published references, posting demos to community sites, and occassionally presenting at meetings of the local .Net User's Group. WPF enables you to do some amazing things, and I LOVE it... but I always feel obligated to qualify my recommendations, whenever developers ask me whether I think they should be moving to the new technology.
- Are your developers willing (preferrably, EAGER) to spend the time it takes to learn to use WPF effectively? I never would have thought to say this about MFC, or Windows Forms, or even unmanaged DirectX, but you probably do NOT want a team trying to "pick up" WPF over the course of a normal dev. cycle for a shipping product!
- Do at least one or two of your developers have some design sensibilities, and do individuals with final design authority have a decent understanding of development issues, so you can leverage WPF capabilities to create something which is actually BETTER, instead of just more "colorful", featuring gratuitous animation?
- Does some percentage of your target customer base run on integrated graphics chip sets that might not support the features you were planning -- or are they still running Windows 2000, which would eliminate them as customers altogether? Some people would also ask whether your customers actually CARE about enhanced visuals but, having lived through internal company "Our business customers don't care about colors and pictures" debates in the early '90s, I know that well-designed solutions from your competitors will MAKE them care, and the real question is whether the conditions are right, to enable you to offer something that will make them care NOW.
- Does the project involve grounds-up development, at least for the presentation layer, to avoid the additional complexity of trying to hook into incompatible legacy scaffolding (Interop with Win Forms is NOT seamless)?
- Can your manager accept (or be distracted from noticing) a significant DROP in developer productivity for four to six months?
This last issue is due to what I like to think of as the "FizzBin" nature of WPF, with ten different ways to implement any task, and no apparent reason to prefer one approach to another, and little guidance available to help you make a choice. Not only will the shortcomings of whatever choice you make become clear only much later in the project, but you are virtually guaranteed to have every developer on your project adopting a different approach, resulting in a major maintenance headache. Most frustrating of all are the inconsistencies that constantly trip you up, as you try to learn the framework.
Here are some considerations I'd suggest are important, to avoid making a big mess with WPF...
- Embrace Xaml If you're writing code-behind to define more than the tiniest fraction of your layout, to quote Mae West, "you're not doin' it cor-rectly!" Xaml was invented for a reason. It makes it easy to switch styles, support designer tooling, and often simplifies the implementation to an almost unimaginable degree, but I constantly see developers writing large volumes of code when they should be writing a tiny amount of markup. Here, for example, is something that amazes alot of people; a fully-functional WatermarkTextbox implemented using just 3 lines of Xaml, leveraging the BooleanToVisibilityConverter provided by WPF.
<Grid Background="{StaticResource brushWatermarkBackground}" >
<TextBlock Margin="5,2" Text="Type something..." Foreground="{StaticResource brushForeground}"
Visibility="{Binding ElementName=txtUserEntry, Path=Text.IsEmpty,
Converter={StaticResource BooleanToVisibilityConverter}}" />
<TextBox Name="txtUserEntry" Background="Transparent" BorderBrush="{StaticResource brushBorder}" />
</Grid>
There are some exceptions, especially when it comes to animation and setting DataContext but, in general, layout = markup, and you usually should not need to resort to code-behind just to set control properties.
- REALLY Embrace Xaml! If you're excited that VStudio sp#1 now features an "event" button, and you're waiting for point-and-click support to cover all the essential WPF features you will use regularly on actual projects (DataTemples, for example)... good luck! It only takes a few weeks to become completely comfortable with direct manipulation of Xaml, and this is infinitely faster than searching through property lists, and results in much more succinct, maintainable mark up.
- Rely on DataTemplates This is another area where even some very experienced developers seem to completely miss the point. Just the other day, I watched a presenter's WPF demo include newing of ListItems in code-behind, with object references attached through the "Tag" field. As many WPF authors have emphasized, WPF supports a true "data centric" implementation model, enabling you to do things like simply bind a high-level container directly to a collection of objects, defining a DataTemplate to specify the visual representation an object of that type should take when it appears in the list. Otherwise, you end up using WPF to write Windows Forms code.
- Go Easy With Custom Control Templates Many published WPF resources and online tutorials focus heavily on the ability to replace the appearance of any control, simply by defining an alternative ControlTemplate. Unfortunately, this can lead developers to whip up new templates for things as simple as a request for a ListBox with rounded corners, when they could simply center a ListBox with a Transparent background over a rounded Rectangle. The volume and complexity of markup in many of the standard control templates (along with accompanying color and component definitions), is non-trivial, and trying to maintain edited local copies of more than a few could grow to become a problem.
- Learn Blend - but REFACTOR ITS OUTPUT! Animation and other visual effects can often really only effectively be designed using a tool like Expression Blend. Unfortunately, Blend's simple point-and-click interface encourages generation of massive amounts of convoluted Xaml, which must be refactored early and often if you expect to have any hope of maintaining the source. Members of the developer community, including some inside Microsoft, have discovered benefits in keeping Blend and Visual Studio project activity separate -- even to the point of manually cutting and pasting carefully-refactored versions of Blend-generated Xaml into the "official" project source, rather than allowing designers and developers operate directly on a single shared code base.
MS User Experience Team UK - Lessons learned in teaming devs and designers on actual WPF projects
Billy Hollis demos a very nice UI, discussing design/dev. lessons learned on an actual WPF project
- It Really is REQUIRED Reading I believe that someone else in the developer community has already stated that WPF makes it much easier to generate a more hopeless mess far faster than was ever possible using any previous Windows development technology. In order to make any sense of the pros and cons associated with the array of implementation choices, I recommend that you start by reading Nathan cover-to-cover (things seem to start making sense around the third reading), work your way through Sells, MacDonald, and Anderson, and keep a copy of Petzold on hand as a reference of last resort. As always, even the most definitive resource was out of date on the day it was published, and you must monitor online feeds for the latest information on feature changes, best practice recommendations, and working implementations you can simply borrow.
Update (9/22/08): I laughed out loud when I first came accross the title "Teach Yourself WPF in 24 Hours" in a bookstore recently, but I found this to be an AMAZINGLY good book! It covers all the major areas of WPF succinctly and clearly, using non-trivial examples that are applicable to real-world projects, and even manages to sqeeze in mention of architecture and process issues that are usually ignored. I had some minor quibbles with some of the material, including the decision to use the MVP (Model-View-Presenter) pattern in all of the examples, but its still an excellent book. Don't get me wrong. You absolutely can NOT learn WPF in 24 hours, but you CAN get an excellent introduction to WPF concepts and techniques in the three to four days it will take you to get through this material, and I highly recommend that you start here, even if you've already had some exposure to the framework.
|