ARC18: Achieving Balance
Rockford Lhotka
It is all too easy to become fixated on the latest trend. Even if we know there’s no “silver bullet” it is so tempting to become “pure OO” or “pure SOA” or “pure anything.” Of course, reality is messier. Real applications require a mix of technologies and concepts, including SOA, messaging, OO, client/server, workflow, and more. At the same time, it isn’t chaos. Each technology fits perfectly in some cases, acceptably in others, and must be coerced into still others. You can achieve balance by using the right technology to solve the right problems. The key is to start with a flexible architectural philosophy, and to fit technologies into that technology without being overly affected by marketing hype or developer enthusiasm for the latest fad. Learn about one such architectural philosophy and how it can be used to frame the use of the many Microsoft technology offerings available today.

ARC07: Architecting Custom Test Automation with Visual Studio Team System
James McCaffrey
Writing lightweight custom test automation harness with languages such as C# and Perl has several advantages over using commercial or open source test frameworks. However, the primary disadvantage of custom test automation is manageability; your test effort can be overwhelmed by the sheer volume of test case data files, test scripts, and test result files. Visual Studio Team System provides you with the ability to design and manage a test effort which includes custom test automation. Topics covered include: understanding test architecture, creating a Generic test type, managing custom test automation, emitting detailed .trx test results, and managing test result storage. You will leave this session having a firm grasp of how and when to use Visual Studio Team System to manage custom test automation.

ARC16: Architecting, Designing and Implementing Your Data Access Layer
Dino Esposito
For years, architects designed applications modeling the domain of the problem through objects. And, for years, architects dealt with the conceptual and technical difficulties of persisting an object model to a relational DBMS. A generally agreed abstract model exists for the data access layer of a system that includes a persistence layer and a service layer for scripting the domain object model. Inside this overall model, though, a number of equally valid approaches may be taken that result in even significantly different architectures and may require different implementation technologies. In this session, we’ll first review the general scheme of a data access layer, and then drill down into options and technologies for the persistence and service layers. Along the way, we’ll touch on concrete technologies such as LINQ to SQL, LINQ to Entities, products such as commercial O/RMs, and patterns such as Active Record, Data Mapper, and Unit-of-Work.

ARC17: Architects: How Do they Happen?
Rockford Lhotka
In a company where I worked we lost an employee with six months total experience because we wouldn’t promote him to “architect”. Another company hired him in that role a week later. Is it possible to be an architect with six months experience? Six years? What is it that makes some people valuable architects after just a few years, while others never even come close? Is it possible to cultivate architects? Train them? Or do they just spontaneously “get it”? Nearly every organization is crying out for quality architects at the enterprise, application and systems levels. Come join in this nature vs. nurture debate. Learn what personal attributes you should look for or cultivate in prospective architects. Learn some techniques that do (and don’t) work, and information that will directly apply to your organization as you try to hire or create your own architects.

ARC11: Block Based Development
Kathleen Dollard
Applications run today in chunks. They reside in thin and thick layers on intelligent devices, web servers, and application servers. We chop up applications across logical data tiers, physical location, and ownership. This session focuses on the human scale engineering behind these chunks and the tools available to manage these blocks in the broader picture of your application—comparing and contrasting services, workflow activities, and plug-ins/add-ins. You’ll see how these differing approaches are synergistic as this session spends a lot of time with how to leverage them working together—including add-ins supporting services, workflows calling services, and services calling workflows. You’ll leave this session better prepared to choose the right tools to build application ecosystems developed and maintained in manageable blocks that can be individually prioritized and completed by reasonably-sized teams in response to business requirements.

ARC12: Bridging Agile and Formal Development Methodologies
Ken Spencer
Many organizations today are choosing to use some form of Agile process such as Scrum or MS Agile for development. But many of these same teams are faced with more and more formal oversight. This session drives into the real-world aspects of bridging these two worlds. We will discuss lessons learned from major project failures that were resurrected with a blend of both Agile and formal processes.

ARC10: Code Generation in the Enterprise
Kathleen Dollard
Code generation offers one of the most viable options for directly expressing the details of your architecture throughout your enterprise. You’ll retain confidence that the architecture is being used correctly, limit or generate certain types of tests, and allow evolution of the architecture under your control. This session covers an introduction into template styles and then moves on to focus on the big picture of code generation in a tool-neutral manner. You’ll see approaches to extracting metadata stores, managing template sets, providing enterprise configuration, protecting handcrafted code and versioning templates. Whether you’re new to code generation or ready to improve its effectiveness in your enterprise, you’ll leave this session with new perspectives and new techniques.

ARC03: Domain-Driven Design—Part 1
Dino Esposito
Business logic represents what the application needs to do for the domain you’re working in. Business logic includes input-based calculation, validation, and dispatch of commands to data sources. Ideally, the business logic completely hides the data sources and reports to the presentation layer. How would you organize such logic? What’s the best and most commonly used approach? And what are the alternate solutions? In this session, you’ll get up close and personal with common-use patterns for modeling business logic and understand their relationship to existing software technologies such as table adapters and LINQ to SQL. You’ll see pros and cons of the Transaction Script pattern and understand the reasons that made the Table Module pattern so successful in .NET applications. Finally, the session will cover the pillars of the Domain Model pattern, the most sophisticated and powerful pattern for business logic.

ARC04: Domain-Driven Design—Part 2
Dino Esposito
Domain-driven design (DDD) is a possible approach to developing software in the context of complex (and typically enterprise) scenarios. DDD is not for just any software project, even though its principles sound usually attractive to almost any developers and architects regardless of the context in which each operate. The primary goal of DDD is accelerating the development of software in projects that have to deal with quite complex domains. DDD focuses on the problem’s domain and related logic and requires that you base your design on a domain model. The domain model comes out as completely decoupled from its persistence layer which raises the need for an OR/M tool to serialize and deserialize the model to and from a data store. In this session, you’ll understand the motivation for DDD and explore patterns that provide guidance on how to effectively design the model for your scenario.

ARC14: I am not an Architect, I am an architect
Dr. Neil Roodyn
In this session the rebellion can begin. Dr. Neil will discuss why he will never consider himself to be an Architect and why many of the concepts of architecture in relationship to software is wrong. Writing high quality code means every developer needs to understand architecture and yet no one developer should be The Architect. In the world we live in software Architects have meetings and developers write code, who is really the architect anyway? The software industry consistently fails to deliver the expected results and in some circles the solution is seen to be the Architect role, often this is not the issue. We have all the answers, we don’t always know when to use these answers to get the results we want. In this session, we will try to help you apply your skills at the right times and know when to just write code. Come to this session for a lively discussion and debate around the concepts behind software architecture and the role of the Architect.

ARC06: It’s All Wrong! Change it All!
Dr. Neil Roodyn
Sometimes we make mistakes. Yes it’s true and if you are mature enough to admit that you don’t always get it right first time then this session will help you. In this session, you'll learn a set of recovery practices that can help you radically change the underlying architecture of your software without impacting the functionality you have already built. This session is about much more than just refactoring. Dr. Neil will discuss the pain of making these changes in terms of the impact to the egos of the developers that built the software, the clients that are paying for the software, and the people managing the project and leading the development team. Change can hurt; consider this session your first step in the recovery process.

ARC15: Routing Patterns for Your SOA
Michele Leroux Bustamante
Services deployed within a SOA environment often require a routing service to provide necessary security boundaries within the architecture; to provide asynchronous logging and message tracking services; for capacity planning or priority routing; for content-based routing and more. This session will illustrate relevant routing architectures; discuss semantics for mixing transports between client, router, and service; explain the semantics of SOAP addressing that are relevant to the routing process; discuss the differences between pass-through routers and processing routers in how they handle messaging protocols; and explain how security can be handled between client, router, and service.

ARC08: Service-Orientation: Where We Are and How Did We Get Here?
Juval Lowy
Contrary to common wisdom, service-orientation is not just for high-end applications. Every application should be service-oriented. But what is service-orientation really about? What does it mean for mere developers? Is there substance behind the hype? In this conceptual session, Juval will demystify service-orientation for you, examine the history of software engineering, and introduce the basic motivation for service-oriented applications and their operating principal and concepts.

ARC09: Service-Oriented Development Process
Juval Lowy
When you develop a service-oriented application, it would be naive of you to expect that the only things you will do differently will be limited to design and technology. The development process itself needs to be service-oriented. You cannot "stare into the fire" without a mature service-oriented development process supporting your effort. This session presents you with a service-oriented development process that you can apply to your SOA-based products to achieve robust applications, manage requirements, plan and track your progress, and ensure faster time to market.

ARC02: SOAP/WS-* and REST: Complementary Communication Styles
David Chappell
Two approaches to creating Web services are most visible today. One, using SOAP and the WS-* specifications, follows in the footsteps of earlier distributed computing technologies. The other, the RESTful style, is explicitly based on the principles of the Web itself. Both have value, and going forward, both will certainly be used. This session describes these two approaches, looks at when each one makes sense, and shows how Windows Communication Foundation (WCF) can support applications built using either style.

ARC05: Software Architecture for Real-Time Systems
Dr. Neil Roodyn
Does your software performance suck? Does it take over a second for your application to load? Come to this session and find out how to improve performance. Software architectures often overlooks one of the most important issues in software today, performance. In both soft real-time and hard real-time systems there are software architectures that can be applied to make the systems you build behave in a timely manner. In this session, Dr. Neil (who holds a PhD in Software Architecture for Distributed Real-Time Systems) will discuss the common issues with building software that has high performance patterns that can be worked towards in order to increase the performance of your software.

ARC13: Solving the Build/Deploy/Install Problem and Smoothing Out Application Test Cycles
Ken Spencer
Most large projects fail for a variety of reasons. One of the key ones is the lack of a reliable automated build / deploy / install system. This session will discuss how to solve this problem using MSBuild, TeamBuild and other Microsoft technologies, and discuss how other 3rd-party products can fit as well. The session is built from lessons learned on two major projects with large development teams.

ARC01: The Hidden Architect—Building Solutions for Smaller Organizations
Dan Appleman
Large enterprises and governments with large projects can justify and afford formal system architecture and design, and can afford the loss when a project self-destructs (as they so often do). But what about smaller businesses and their web applications? These organizations fall victim daily to poorly designed solutions that aren't what they needed in the first place. They need help figuring out what they really need—help they often don't realize they need and are reluctant to pay for. It's not enough to be a web or application developer when it comes to this kind of client or project—you have to be a system architect as well, even though you don't wear the title and may not be able to charge for the service. So how do you become a system architect? This session might be a good start. We'll cover requirements, economics, client management, creative and flexible design strategies, and how to look beyond "best practices" design patterns to find solutions that fit the client, instead of trying to fit the client to the solution. P.S. Bring your favorite horror stories for show and tell!

IASA SESSIONS

IASA13: "Design Patterns" in Dynamic Languages
Neal Ford
The Gang of Four book was actually 2 books: a nomenclature describing common software problems and a recipe book for solutions. The vocabulary they defined is still useful. The recipes are a disaster! Dynamic languages (like Groovy and Ruby) have powerful meta-programming facilities far beyond statically typed languages. It turns out that many of the structural design patterns in the Gang of Four book and beyond are much easier to solve with meta-programming. This session compares and contrasts the "traditional" approach of design patterns with a more nuanced meta-programming approach. Using language features creates cleaner abstractions with fewer lines of code and little or no additional structure. This session shows one of the many reasons that dynamic languages are such a hot topic.

IASA01: Anti-Patterns in Software Projects: The Human Factor
Rob Daigneau
The creation of software products is a highly complex endeavor. One methodology after the next is touted as being the solution to smoother project execution, but the pundits never seem to account for the chasm that exists between academia and reality in the corporate world. This chasm exists because of the human factor—the ingredient which ultimately has the greatest influence upon the success of any software project. Join us in this session to see how people, teams, leadership styles, and politics can subvert the benefits that we should be realizing from strategic architecture plans, modern methodologies like Agile, and IT governance processes. We will identify some of the common anti-patterns attributable to people and organizations, and look at ways to address these self-defeating behaviors in a positive manner.

IASA08: Architectural Strategies, Patterns, and Forces for High-Volume Web Sites
Randy Shoup
Websites, services, and enterprises are increasingly faced with growing demands—more users, more traffic, more data. Learning principles and patterns for scaling helps architects and developers in those organizations meet and exceed those demands. This session covers the fundamental architectural principles eBay has followed to grow and evolve its infrastructure to a massive scale. It covers the forces (or “-ilities”) architects need to contend with and design for—scalability, availability, manageability, etc. —and outlines eBay’s core set of architectural strategies that meet—and trade off—those forces. This session offers reusable patterns for each strategy, and provides specific examples from the eBay infrastructure to illustrate the patterns in action.

IASA05: Breaking the Super Platform Bonds
Chris Haddad
Proprietary programming interfaces, ‘free’ capabilities, 24/7 support, comprehensive infrastructure suites, and integrated tooling provide application teams with compelling reasons to tightly couple applications and services to super platform offerings (e.g IBM WebSphere, Microsoft .NET/Visual Studio, Oracle Fusion Middleware, BEA AquaLogic, and SAP Enterprise SOA). While super platform infrastructure components are the default choice for projects, the platform choice often results in high licensing fees, steep learning curve, capability compromises, and heavy-weight production deployments. Enterprise acceptance of cloud-hosted infrastructure services, open source, rebel frameworks, and Software as a Service threaten super platform dominance and are tipping the balance of power away from incumbent vendors.This session explores the forces breaking the Super Platform bonds including: cloud computing and infrastructure services; Software as a Service (SaaS) and open source business models; emerging platform vendors (e.g. SalesForce.com, Google, Amazon); specialty vendors; rebel frameworks; and virtualization.

IASA14: Evolutionary SOA
Neal Ford
Managers and ivory tower architects seem to think that all the rules that apply to "normal" software don’t apply to SOA. Ironically, they matter even more. Agility and SOA are closely aligned because SOA is about building complex distributed systems and Agility is about effectively building complex software. This session unveils the pillars of successful SOA and how to achieve them in a testable, iterative fashion. It discussing testing strategies, how to make your architecture more robust and maintainable, and how to design an evolutionary architecture.

IASA20: Federated Security Implementation Patterns
Michele Leroux Bustamante
Federated security models are a fast-growing necessity for enterprise systems to normalize application authentication mechanisms, to provide more granular control over the security model, and to support single sign-on (SSO) to applications and services. The participant and protocols involved in a federated security model are consistent across technology platforms with Web services standards such as WS-Trust, WS-Federation, and SAML living at the heart of it. This session will explore the participants in a typical federated security model and illustrate several authentication and authorization implementation patterns that impact how security tokens are generated, the claims they carry, and the way that applications and services authorize access. Available platforms for implementing federated security models will also be discussed.

IASA07: How to Manage and Control VM Self-Provisioning
Russ Gibfried
In the corporate environment, delegating VM self-provisioning tasks to your user community allows your customers to quickly setup, build, and tear down complex solutions on your host’s datacenter, with little knowledge or concern about the hardware and network infrastructure required. For architects, VM self-provisioning promises users a more flexible environment where they can rapidly respond to business needs. But how do architects and administrators control their virtual infrastructure so they can provide the flexibility and attractiveness of the model, and still meet enterprise requirements for security, stability, and reduced costs? This session provides real-life examples using Microsoft System Center products Virtual Machine Manager 2007, Operations Manager 2007, and Configuration Manager 2007 to provide SAIC line organizations a secure virtual environment to develop high impact solutions.

IASA10: Pragmatic Architecture
Ted Neward
Building an application is not the straightforward exercise it used to be. Decisions regarding which programming languages to use (Java, .NET, even FoxPro), which architectural approaches to take (n-tier, client/server), which user interface approaches to take (Smart/rich client, thin client, Ajax), even how to communicate between processes (Web services, distributed objects, REST)... it's enough to drive the most dedicated designer nuts. This session discusses the goals of an application architecture and why developers should concern themselves with architecture in the first place. Then it dives into the meat of the various architectural considerations available; the pros and cons of JavaWebStart, ClickOnce, Windows Presentation Foundation, SWT, Swing, WinForms, Struts, WebForms, Ajax, RMI, .NET Remoting, JAX-WS, ASMX, Windows Communication Foundation, Windows Workflow Foundation, JMS, MSMQ, transactional processing, and more. After that, the basic architectural discussion from the first part is, with the aid of the audience in a more interactive workshop style, applied to a real-world problem, discussing the performance and scalability ramifications of the various communication options, user interface options, and more.

IASA11: Rethinking Enterprise
Ted Neward
The era of the big, heavy, transactionally-oriented client/server topology, as best described by the J2EE Specification and Blueprints document, seems to be over. The era of the lightweight, transactionally-oriented client/server topology seems to be at its zenith. Is this really where we want to be when building enterprise systems? And how did we end up here, anyway? What's the new "enterprise" developer supposed to do?

IASA16: Security 101: An Introduction to Software Security at the Architectural and Process Level
Allen Holub
As more and more of our applications move onto the Web, security becomes even more critical. Good security, however, has to be built in, not tacked on as an afterthought. Misconceptions about security—that an application can be made secure solely by using encryption (https) and firewalls, for example—bound. Moreover, security is more an architectural (at both the system and program level) and process problem than a coding problem. This session gives you an overview of what it means to make an application truly secure. We’ll start by looking at a couple common attack scenarios so that you can understand the sorts of things that make an application vulnerable, then we’ll talk about how to design and build your applications so that they will be truly secure. Covered topics include security architectures, code and design review, penetration testing, risk analysis and risk-based testing, security-related requirements, static analysis, abuse cases, security operations, and crypto.

IASA02: Service Aspects—Aspect Orientated Designs in Distributed Enterprise Architecture
Adnan Masood
Aspect Oriented Programming and Aspect-Oriented software development (AOSD) support the software development paradigm which leverages separation of concerns, especially cross-cutting concerns as a next step to modularization. Separation of concerns can be defined as breaking down a program into distinct parts that overlap in functionality as little as possible. The similar concerns are factored and defined as aspects which are separated out from the main logic making the implementation more maintainable. In this session we approach the service orientation as an aspect of a distributed system. Using attribute oriented design for aspect implementation, this presentation focuses on merits of exposing service end points from business objects by using AOP practices. The attendees will: gather the understanding of AOP, a fast growing research and development area in modern software development; understand the state of affairs of AOP in the current IDE’s and programming languages especially with Spring, AspectJ and Aspect.NET; explore the rationale of aspect-based nature of services and deep dive into the open source ServiceAspect CodePlex project for a sample implementation. This session’s focus is the architecture and design practices that AOSD brings to the enterprise architecture. Best practices and design patterns followed in AOP will be discussed with a demo of Aspect.NET and ServiceAspect, which is used to publish business objects as WCF services using attributes.

IASA06: SOA Report Card
Chris Haddad
Everyone seems to be doing SOA, but how many organizations are doing it well? Is anyone making a passing grade? Burton Group has been conducting intensive research into real-world SOA initiatives. The research is focused on SOA planning and execution. It compares and contrasts top-down and bottom-up approaches. It explores organizational and cultural impediments. It examines governance strategies. It also looks at business models and metrics. We’ll present our findings from this research in this session. Learn what works and what doesn’t: Where do you start?; How do you identify, model, and describe services?; Is an ESB a prerequisite?; What about WS-* versus REST?; When do you really need to establish governance?; How much governance is required?; What changes are required to the organization, funding models, development practices, etc?; How do you measure success?

IASA15: Test Driven SOA Development
Frank Cohen
Software architects and developers have adopted "test first" software development strategies widely. Unit test frameworks for Java, .NET, Web services, Ajax, REST, and Service Oriented Architecture show the diversity of adoption. In this session, Frank Cohen will identify a new methodology to repurpose unit tests as functional tests to conduct acceptance and regression testing. Cohen will show how to repurpose these tests without any extra effort as load and performance tests to understand the Scalability Index of a service for hardware, software, and resource forecasting. Cohen will then show repurposing these tests as business service monitors to prove Service Level Agreement (SLA) compliance. Cohen will then show how you accomplish this using open-source and commercial test tool platforms.

IASA09: The Busy Architect’s Guide to Rules and Rules Engines
Ted Neward
If you've been keeping your ear to the ground, you may have heard some talk recently about "rules", "business rules" and "rules engines", but not necessarily any clear discussion on what they are, how to use or design them, or why they might be useful or important. This presentation puts some concrete definition around what a "rule" is, how a "rule engine" like Drools (a.k.a JBoss Rules), JESS or the rules engine found in Windows Workflow can enable your users to be more agile than they ever thought possible. We’ll also talk about where it fits into both the WCF/WF/BizTalk, J2EE, Spring and "lightweight" development environments, and how you can (finally!) get out of the "infinite if-else game".

IASA17: The Object-Oriented-Design Process and UML
Allen Holub
Good OO designs are typically the result of an orderly process: problem-statement definition, use-case analysis, dynamic modeling, and class design (typically in that order). Every stage of that process involves artifacts, both in English and in UML. UML, however, is just a notation—a way to make your design ideas clear on paper. Many people learn the notation, however, without any idea of how that notation integrates with the design process. Even worse, many people see UML as, somehow, a process of its own. This session provides a succinct overview of the OO-Design process, showing you how UML (and other artifacts, such as the user-interface design) integrate into that process. It’s a big-picture class, showing you how the entire design process works, and how the various parts of the process interact with one another, rather than focusing on one aspect of that process (like modeling).

IASA03: Tracking, Monitoring, Metering and Measuring Your SOA
Anant Kadiyala
SOA has evolved from pilot projects to mission-critical initiatives. Today, most companies understand the benefits of SOA, but are grappling with the challenges involved with the execution. In this session, we delve into the metrics that are crucial to keep your SOA initiative healthy and on the right track. We will discuss a range of technical, people and process metrics that need to be closely monitored and managed closely. We will also discuss tools and best practices that can be leveraged to manage your SOA.

IASA18: Using Java Message Service as the "Glue" in Heterogeneous Enterprise Architectures
Wayne Citrin
Enterprise architectures based exclusively on Java Enterprise Edition (JEE) technology have long relied on Java Message Service (JMS) as the communications "glue" that holds together the disparate components. But, as other non-JEE technologies like .NET are added to the mix, how can these new components communicate with the existing infrastructure? The problem becomes even more severe when the existing components can't be modified. This session will discuss how JMS can continue to be used as a messaging infrastructure even when components are based on platforms other than JEE. We will start with a brief discussion of JMS fundamentals, followed by a discussion of the use of JMS over Web services, and of various cross-platform approaches using native JMS wire protocols. The advantages and disadvantages of each approach will be discussed, and guidelines and best practices will be presented. Each approach discussed will be accompanied by a demo.

IASA19: You're Not an Architect, but Neither Am I
Paul Preiss
In this session we will delve into the nature of the architecture profession. What is the difference between a developer, engineer and software architect? Does an architect think differently? What exactly are their skills? Is there a difference between architecture and design? How does one become an architect? How many different opinions and perspectives on the role exist in the industry (you will be surprised by this)? Most importantly, we will discuss the two years of discussions, research, opinions and development by IASA members on what it really takes to be a software, infrastructure or business architect.

IASA KEYNOTE

IASAKY: Data Architecture and Beyond: Agile Approaches for Addressing Data Quality Challenges
Scott Ambler
Data has always been a critical architectural aspect of business systems and of enterprise infrastructures in general. Yet it is estimated that data quality challenges lead to a $600 billion productivity loss annually, a clear indication that traditional approaches to data architecture, data management, and data governance have failed to live up to their promises. Without a solid data foundation in place there is little hope that modern, services-based architectures will succeed. This keynote explores the technical and cultural challenges surrounding data-oriented activities, compares and contrasts potential strategies for addressing data quality problems, and in particular focuses on agile strategies and techniques for doing so.

ARCHITECT CONNECTIONS KEYNOTE

ARCKEY2: Software + Services: A Perspective
David Chappell
The move to service-orientation is well underway, both inside enterprises and on the Internet. What role does traditional software play in a world of on-line services? In particular, how is Microsoft approaching the combination of software plus services? In this keynote presentation, David Chappell examines this important area, providing an overview along with a perspective on this emerging combination.

ARCKEY: Why Software Sucks
David Platt
Users think that today's software sucks. It's unsafe, it's unreliable, and it's hard to use. These problems are not technical. We've been able to solve them for many years, but instead we've gotten a paper clip with eyebrows. Why? Software sucks because developers forget (or never knew) the bedrock principle of software development: KNOW THY USER, FOR HE IS NOT THEE. For example, what do your customers come to you for? Hint: It's not software. For another example, do you think your users care about your application? They don't. Never have; never will. They care about accomplishing the task that it does. They don't want to think about you or your application at all. It's your job to care about them anyway. We show good and bad examples from commercial software and Web sites: those that understand and help their users, and those that treat users with contempt. For example, consider the ads for Microsoft Office that show non-upgrading users wearing plastic dinosaur heads. Developers fear looking like dinosaurs by not having the latest technology, but ordinary users fear breaking an installation that currently works, or having useless junk like dancing paper clips slow down their computers so they need to buy new ones. Your user is not you. We put this nation on wheels not by training the entire population as mechanics, but by improving cars so they didn't often need mechanics. The same transition needs to happen to the software industry. This talk provides sound design principles so that your software won't suck. Learn how blindness will improve your vision.