August 25, 2002

Builder.com May 1, 2002 The architect's role in team development One of Microsoft's key assets is its continual investment in research and development (R&D). Its R&D budget is larger than most companies' annual revenues. But the company doesn't just spend its R&D money on investigating new products and services; Microsoft also makes significant investments in the human factor (i.e., looking at how people use existing products and what improvements can be made to enhance the usability of those products). As part of the product planning for Visual Studio .NET, Microsoft did extensive analysis of how enterprise architects participate on development teams and what tools it could provide to make the architect's job easier and his or her time more productive. The architectural investment So what did Microsoft discover when analyzing the role of the architect? Its major conclusion was that although companies invest millions of dollars each year in designing and architecting their systems, much of the investment never makes it into the final product because there's no effective way to disseminate the architectural recommendations and, more importantly, enforce key architectural decisions about any particular application design. Microsoft also found that companies using external contractors have an additional complicating factor in the design-to-product investment. Contractors often use their own tools and methodologies, which tend to detract from, rather than enhance, their customer's internal architectural recommendations. Based on these observations, Microsoft added some key features to the Enterprise Architect version of Visual Studio .NET. Propagating architectural decisions The most common approach to publishing architectural decisions to the rest of the development community is to put up a "standards" Web site or publish architectural documents for specific projects on an intranet project's Web. The problem with either approach is that asking programmers to be proactive about reading architectural documents before beginning a project, or referring to them during a project, is like asking a teenage boy to call home when he goes out with his friends: It's just not going to happen. To help companies enforce architectural policies, Microsoft included Enterprise Template functionality in the Enterprise Architect version of VS.NET. Enterprise Templates allow system architects to provide architectural blueprints, reusable components, development policies, or instructions delivered in the context of a particular application. Templates include two key elements. First, the template project includes an initial structure for an application, standard components allowed in the application, and any reusable internal components or systems appropriate for this particular project. (For examples of how these policies work, you can launch Visual Studio and select File | New | Projects | Other Projects | Enterprise Template Projects and choose from templates like Business Facade, Business Rules, and Data Access projects.) The template project policies are enforced by the second key template element--a policy definition file. The policy definition file includes a set of instructions for what a developer can't do in the development environment. After a project template and policy file are developed, these are deployed to a development workstation. When the developer selects one of these projects, Visual Studio first creates an initial project structure from the template. Then it applies the policy file, which customizes elements of the Visual Studio IDE, including the TaskList, Toolbox, Property Browser, Server Explorer, and Help System. For example, an architect could develop a template for developing Windows clients for the Help Desk System. The template would include a base Windows form, Help Desk business objects with predefined references, and load the Help Desk technical documentation into the help system. The TaskList could be preloaded with instructions on creating a new form by inheriting from the base Windows form, as well as directions for starting the application using the supplied business objects. More importantly, the TDL file can remove all of the controls from the Windows forms palette that shouldn't be used in this application. It can also remove all of the data objects from the data palette and disallow all references to the System.Data namespace to insure that the developer only accesses the Help System data using the supplied business objects. Although many developers will complain about the restrictions imposed by these templates, they're one of the most effective ways to ensure that companies benefit from the investment they've made in systems architecture and design. Using the templates also makes it much easier to enforce architectural policies when using outside contractors. As founder and president of eAdvantage, Tim Landgrave provides business strategy consulting services to VARs and xSPs. 3:40:59 PM     #21: Designing on both sides of your brain By Scott Berkun, scott@uiweb.com Someone once asked me if, as a thinker, I was rational or creative. Left brained or right-brained. I considered it, and asked in reply, do I have to choose? Is it possible to be both? I didn’t think I could afford to discriminate. I wanted to be good at designing things, and I needed all the brainpower I had available. Later in life, having read about our best thinkers and problem solvers, I learned that there is a natural balance that can be mastered between both intensely imaginative, and passionately logical lines of thought. It’s my claim, echoing many people before me, that we need to seek out this synergy to be good at design. The myths of rational thinking and the methods of science Before learning about design in college, I studied advanced logic theory. At parties, it was the last thing I wanted to mention, since it was certain to bring yawns and glares of boredom from beer-holding peers. The general reputation for the subject was that, like mathematics and science, it was dreadfully dull. These fields were seen as predictable and highly structured: you learn a formula for this, an equation for that, repeat a proof someone discovered decades ago, and then call it a day. It followed that the scientific method, considered a pillar of progress in the academic world, had an equally poor reputation. But this status is decidedly unearned. The surprising truth is that for designers everywhere, the scientific method can be an extremely powerful tool for finding and evangelizing your great ideas. The ultra-compressed version of the scientific method has two parts. Part one: when you have an idea, you must expend time and energy to prove that it works. Part two: you must also expend time and energy trying to prove that it doesn’t work. That’s it. Welcome to the world of science. This simple set of two different approaches to evaluating ideas can improve the quality of your entire thought process, and the value of the work you produce. The power of the method is that it asks anyone who would call themself a scientist, or a designer, to attack problems from both sides. It’s not enough to take a pet idea and make claims about its value. Instead, you must seek an objective view of the idea, and invest time in disproving your own claims. If it truly is a good idea, it should be able to withstand the scrutiny of your critical evaluation. If it crumbles under your own inspection, you will have saved your team, and your users some time by returning yourself to the drawing board without interrupting anyone else. The value to designers is twofold: First, it improves the clarity with which you view your work. Your ideas might be good in some abstract sense, but we should not confuse them with meaningful solutions to the customer or business problems at hand. Second, by making yourself comfortable with critiquing your own work, you improve the quality of any work you output. Like proofreading your own essays, you become more self-sufficient, as a designer. Beyond your design skill, your strength in convincing others of your ideas to your team will improve. Instead of only offering the positive attributes of your design, you can present the challenging questions you asked, and express how your proposed design excelled in the face of those challenges. The more scrutiny you can apply yourself, the more confidence you will have. Even better, your comfort level with discussing designs with others will improve. Your internal dialog about your work will more naturally match your external dialog with peers and teammates. (Note: While many teams thrive on communal critiquing of work in an open and supportive environment, which is good, many others are not so fortunate. The overall goal is not to spend more time in isolation, nor to control your development team like puppets, but instead, to derive a system, both internal and collaborative, for surfacing the best ideas, and delivering them to customers). Live by analysis, die by analysis To the frustration of creative thinkers everywhere, the nature of poor usability engineering can often cause a team to focus on design problems in the narrowest way. Without proper counsel from an experienced usability engineer a team can miss large opportunities, falling into the trap of minimizing problems instead of solving them. Quick changes rarely solve the underlying and systemic causes. Often problems run deep, down to assumptions made early in a project, and manifested at different levels in code. Without the wisdom to look deeper, no amount of usability studies will significantly improve a design. At the most negative extreme, an analysis-dominated development team will achieve only turd polishing: the constant refinement of bad ideas, without any hope of arriving at substantially new approaches to the problem. What’s required to maximize the value of analysis is creative thinking. Knowing when and how to switch gears between analysis and creative exploration is the key. The synergy of solutions Cars are designed to switch gears easily. Modern humans are not. When we learn a technique or a tool, it‚s natural for us to fixate on its use. If you have a hammer, everything is a nail. It follows that people who learn to take comfort in analysis and process, tend to have difficulty rejecting those models, and switching to inspiration and creative passion as their guideposts. Alternatively, the creative-minded often struggle with structured evaluation, or models, methods and processes for problem solving. The good news is that you don’t have to choose. You can be both creative and rational. At the moment when project goals, or usability issues, are identified, someone has to take control of the response. How deep a solution will be required? If shallow corrections or additions are all that are needed, then it’s appropriate to engage in a quick brainstorming session before proceeding in a single direction. But if more serious problems are found, or the project goals are more substantial and involved, deeper exploration into new alternatives is justified. This is where the team has to shift gears and invest in exploration. All problems have multiple solutions. The larger the problem, the more open the solution space. To understand the different choices requires a creative approach. Someone must lead the way in expressing the different possible directions. What are three alternative navigation designs, and how would this improve the design, relative to known customer behavior? Can we reduce the number of categories we have by a third to simplify some user decisions? This line of exploration might be led by someone skilled at asking the right questions, or by a surge of inspiration and expression of ideas by someone gifted in those traits. But the method is less important than the result: A set of alternatives, manifested in prototypes or pictures, that can be compared and evaluated relative to the needs and problems at hand. Comparison vs. creativity? Some designers ruffle at the comparison process. They’d prefer to allow their personal choice of approach to surface as the direction for change. This is almost always a mistake. Often it’s impossible to understand the merit of a design, without comparing it against several potential alternatives. It’s hard to know if something is good or bad if it is standing alone. Recalling the scientific method, it’s in the designer’s interest to work to prove and disprove her own firmly held beliefs. If her heart is concerned with the customer’s experience, she should want the best idea to surface, regardless of her own initial preferences. She should be willing to be convinced that there is another way that’s better, regardless of who came up with it. Often it’s only when comparing two ideas that the best idea—a hybrid of the two—is discovered. At the moment when the team has arrived at some good ideas, hopefully through evaluating the tradeoffs of alternatives, analysis becomes the greatest need. Perhaps there is time for a quick usability study, or heuristic evaluation, to help confirm that the proposed changes will truly have a positive impact on the customer. There are always more details in the world than can be considered by the designer’s mind, and it’s much cheaper to learn from mistakes in prototypes than in production code. Design is a reflective process The entire process of idea exploration, evaluation and implementation is reflective. No one mindset or attitude prevails. Instead, it’s the judgment of the designer, or the team leaders, to approach each kind of problem in the appropriate way. Some moments require an emphasis on the logical and rational. Others demand creative exploration and expression driven work. Often the entire project cycle is spent shifting between different modes of thought, exploring, evaluating, and exploring again. Few things of importance arrive from either/or thinking. It’s the wise and the successful that are able to derive approaches to difficult situations that unify and combine, rather than separate and divide. Think Yin/Yang or chocolate and peanut butter. The greatest opportunities for the mindful designer are in exploring how to build complementary relationships from seemingly competing traits. Hfactor/Uiweb column information This issue can be found online at http://www.uiweb.com/issues/issue21.htm. Column archive, author info, and other design/usability resources: http://www.uiweb.com To get new columns direct via email: hfactor-subscribe@topica.com Question, comment or something you'd like to see me write about?   scott@uiweb.com Copyright (c) 2000-2002, Scott Berkun - All Rights reserved 3:38:04 PM     .NET UPDATE -- brought to you by the Windows & .NET Magazine Network (contributed by Paul Thurrott, news editor, thurrott@winnetmag.com) June 27, 2002 There but for the Grace of the Legal System Go We In a meeting with Microsoft officials last week, I heard a bit of trivia that should have been obvious but that surprised me nonetheless. When asked whether Microsoft would support Sun Microsystems' server-based Java technology in the next Windows .NET Server (Win.NET Server) version, John Montgomery, the group product manager for the Developer Platform and Evangelism Group at Microsoft, said no but noted that Sun was as free to build on Microsoft's server platform as anyone else. Montgomery then explained that the world would have been a very different place if Sun had made different decisions at crucial points in its relationship with Microsoft. Here's what happened, and how things might have turned out much differently. In December 1995, Microsoft announced an abrupt strategy shift in which the company reorganized its business around the Internet. The announcement, touched off by Bill Gates's earlier "Internet Tidal Wave" memo to employees at the company, included a couple of shocking interoperability revelations: Microsoft would expand its licensing of Spyglass's Web browser code to port the Microsoft Internet Explorer (IE) product to Windows 3.x, UNIX, and the Macintosh; and the company would license Java, the popular Web-oriented programming language. Java had an interesting beginning at Sun, the high-end server and enterprise-class UNIX vendor. According to popular legend, developer James Gosling had decided to create a new programming language for a set-top box that the company was then designing but later scrapped. Looking out his office window for inspiration, Gosling saw a tree and dubbed the object-oriented language "Elm." But the name Elm was already taken, so Gosling settled on Java. Over the next few years, Java sat in limbo as Sun's set-top box plans folded. But with the rise of the Internet, Gosling saw that a small and elegant programming language like Java could be quite useful, and so it was redesigned for that purpose. Microsoft originally didn't trust Sun or Java because of the possibility that developers would prefer Java over Windows. Java applications, applets, and services run in a software "sandbox," a protected environment that sits on top of various OSs such as UNIX, Windows, and the Mac OS. If developers were to accept Java as the overlying platform for their OSs, Windows would lose its importance. So Microsoft surprised everyone and licensed the Java technology from Sun. According to the licensing agreement, Microsoft would be able to "modify, adapt, and create derivative works of Sun's Java technology," which is exactly what the company did, creating a Java version that ran better on Windows and offered unique Windows-only features. During 1996 and 1997, Microsoft invested heavily in Java, releasing Java interfaces to various Microsoft applications and creating a Java development environment called Visual J++ (VJ++). The company even held Java-oriented developer events and was reportedly working on Java components for Microsoft Office. A future version of Visual Studio (VS) was going to generate Java byte codes--the underlying executable format that programs written in Java use. The company's distributed Java strategy was interesting. Sensing a move to Internet-based software subscriptions--a term more common today than it was 4 or 5 years ago--Microsoft began adapting its Windows-only component technologies (which the company referred to by the umbrella term Windows DNA) to include cross-platform hooks through Java. Java would have been the gatekeeper, or glue, between software components running on Windows servers. And with Java, Microsoft finally had an interoperability strategy for communicating with non-Windows systems. If you're familiar with what became .NET, the information in the preceding paragraph should sound familiar. But somewhere along the line, Microsoft's plans for Java completely fell apart. Sun sued Microsoft in October 1997 for violating the Java licensing terms. And when it became clear that Sun was going to win the case--as it eventually did in an early 2001 settlement, Microsoft slowly but surely walked away from Java and did its own thing. "Had Sun not decided to compete through the courts, we would have happily continued using Java, and .NET never would have happened," Montgomery said. Faced with the prospect of not being able to improve Java, Microsoft started working up internal strategies for cross-platform, Internet-based subscription software. The company had already hired longtime Borland software architect Anders Hejlsberg, who created the Turbo Pascal compiler and the Delphi Visual Component Library (VCL), to work on Java technologies. Hejlsberg was set to working up a new, Java-like programming language eventually named C#. But C# isn't Hejlsberg's most important contribution to Microsoft. His creation of the logical and powerful class library and runtime environment Common Language Runtime (CLR) is credited with making .NET a huge hit with developers. In some ways, the Sun-Microsoft feud was a good thing. The .NET platform as it now stands is more powerful than anything the company could have accomplished with Sun, thanks to .NET's from-scratch architecture, support for multiple programming languages, and use of standards-based technologies such as XML and Simple Object Access Protocol (SOAP). And, in response to criticism of Sun for not doing the same for Java, Microsoft has taken the high road and worked to make key portions of .NET open standards that are available for anyone to use. Microsoft will also open more of .NET to standards bodies over the next few years, Montgomery said. Sun, of course, is still positioning Java for Web services, and the possibility exists that Java will be in place years from now, working side by side with .NET technologies. But if Sun could have found some way of working with Microsoft, avoided its lengthy and ultimately damaging court case, and positioned Java as an open standard, Sun might have driven the move to the Web services platforms of the future. Instead, although Java will be a player in Web services, its position will probably be as a minor player relegated to non-Microsoft platforms. Do you think Sun would do it differently if it had a second chance? This biweekly email newsletter is brought to you by Windows & .NET Magazine, the leading publication for Windows professionals who want to learn more and perform better. Subscribe today: http://www.winnetmag.com/sub.cfm?code=wswi201x1z. Receive the latest information about the Windows and .NET topics of your choice. Subscribe to our other FREE email newsletters: http://www.winnetmag.com/email.  Copyright 2002, Penton Media, Inc. 3:34:16 PM

© Copyright 2002 Eric Hartwell. Last update: 18/09/2002; 7:30:34 PM. This theme is based on the SoundWaves (blue) Manila theme.

August 2002 Sun Mon Tue Wed Thu Fri Sat         1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Jul   Sep

"Data! data! data!" he cried impatiently. "I can't make bricks without clay."
— Sherlock Holmes to Dr. Watson in "The Adventure of the Copper Beeches" by Arthur Conan Doyle. 

"I like deadlines," cartoonist Scott Adams once said. "I especially like the whooshing sound they make as they fly by."

"There is nothing like that feeling of spending days and days banging your head against a wall trying to solve a programming problem then suddenly finding that one tiny obscure and seemingly unrelated piece of the puzzle that unlocks the solution. Oh yeah!"

- Chris Maunder, CodeProject Newsletter 28 Jan 2002

"Management at eSnipe, which is me, is also feeling the pain of the 2002 bear market. So rather than pout about it, I bought some stuff on eBay that I really didn’t need, but made me feel better."

- Tom Campbell, president of eSnipe