Design and Architecture

Tutorials

MA An Introduction to SAFe: The Scaled Agile Framework

Al Shalloway, Net Objectives

Mon, 06/08/2015 - 8:30am

The Scaled Agile Framework (SAFe) is quickly being adopted by many large organizations that have had some success with agile at the team level but have not been able to scale up to large projects. Al Shalloway describes what SAFe is, discusses when and how to implement it, and provides a few extensions to SAFe. Al begins with a high-level, executive’s guide to SAFe that you can share with your organization’s leaders. He then covers the aspects of implementing SAFe: identifying the sequence of features to work, establishing release trains, the SAFe release planning event, SAFe’s variant of Scrum, and when to use the SAFe process. Al concludes with extensions to SAFe including creating effective teams—even when it doesn’t look possible—and implementing shared services and DevOps in SAFe using kanban. Get an introduction to SAFe, discover whether it would be useful to your organization, and identify the steps you should take to be SAFe.

MI Software Design for Testability

Peter Zimmerer, Siemens AG

Mon, 06/08/2015 - 8:30am

Testability is the degree to which a system can be effectively and efficiently tested. This key software attribute indicates whether testing (and subsequent maintenance) will be easy and cheap—or difficult and expensive. In the worst case, a lack of testability means that some system components cannot be tested at all. Testability is not free; it must be explicitly designed into the system through adequate design for testability. Peter Zimmerer describes influencing factors (controllability, visibility, operability, stability, simplicity) and constraints (conflicting nonfunctional requirements, legacy code), and shares his experiences implementing and testing highly-testable software. Peter offers practical guidance on two key actions: (1) designing well-defined control and observation points in the architecture, and (2) specifying testability needs for test automation early. He shares creative and innovative approaches to overcome failures caused by deficiencies in testability. Peter presents a new and comprehensive strategy for testability design that you can implement to gain the benefits in a cost-efficient manner.

TQ Design Patterns Explained—from Analysis through Implementation

Ken Pugh, Net Objectives

Tue, 06/09/2015 - 1:00pm

Ken Pugh takes you beyond thinking of design patterns as “solutions to a problem in a context.” Patterns are really about handling variations in your problem domain while keeping code from becoming complex and difficult to maintain as the system evolves. Ken begins by describing the classic use of patterns. He shows how design patterns implement good coding practices and then explains key design patterns including Strategy, Bridge, Adapter, Façade, and Abstract Factory. In small group exercises, learn how to use patterns to create robust architectures that can readily adapt as new requirements arise. Lessons from these patterns are used to illustrate how to do domain analysis based on abstracting out commonalities in a problem domain and identifying particular variations that must be implemented. Leave with a working understanding of what design patterns are and a better way to build models of your application domains.

Concurrent Sessions

BW7 What’s In a Name? The Metaphorical Power in Our Ideas

Andy Palmer, RiverGlide

Wed, 06/10/2015 - 1:30pm

Why is naming things so difficult? Look in any reasonably sized code base, and you’ll see—in abundance!— crimes against naming. The Spring framework has a class AbstractSingletonProxyFactoryBean—and there are many worse examples. We in the computer industry tend to name things by what they do, rather than why they do it, and thus rob ourselves of the opportunity to tell an interesting and intriguing story. Andy Palmer says it hasn’t always been this way. In the early days of computing, names were rich with metaphor. Names, that today are synonymous with the concepts, were once compelling and novel stories. Terms such as Desktop, File, and Folder all had analogues in the physical world, and this helped people come to grips with the new concepts. Andy gives some examples of metaphors from the early days of computing, discusses some more modern examples, gives reasons why we might choose to program in this way, and suggests some ways in which we can improve our ability to tell a story through our code.

BT2 Emergent Design: History, Concepts, and Principles

Rob Myers, Agile Institute

Thu, 06/11/2015 - 10:00am

Software design is about change. A good design facilitates adding features—and adding new developers to the team. Yet any change to the code impacts design and can damage existing functionality. Without design idioms and practices, the code can degrade into a maintenance nightmare. Your team must know which decisions to make early in design and which to defer. Rob Myers reviews “families” of design attributes and practices, showing the common principles within each. Exploring emergent design by tracing how the concept itself has evolved and matured over time, Rob covers traditional attributes of good object-oriented code (cohesion, encapsulation, polymorphism, coupling); design patterns and the wisdom discovered within; and S.O.L.I.D. principles—all culminating in emergent design, where simple (not easy) practices meet the simplest of guidelines, such as Kent Beck’s “Four Rules of Simple Design.” And the result is code that is easy to understand and delightful to work on.

BT6 Avoid Over Design and Under Design

Al Shalloway, Net Objectives

Thu, 06/11/2015 - 11:30am

The question of how much design to do up-front on a project is an engaging conundrum. Too much design often results in excess complexity and wasted effort. Too little design results in a poor architecture or insufficient system structures which require expensive rework and hurt more in the long run. How can we know the right balance of upfront design work and emerging design approaches? Al Shalloway shows how to use design patterns—coupled with agile’s attitude of don’t build what you don’t need—to guide your design efforts. The trick is to identify potential design alternatives, analyze how each may affect the system in the future, and then find the simplest approach for isolating those potential effects. Al describes the essence of emergent design—start with a simple design and let it evolve as the requirements evolve—and demonstrates how to refactor to achieve better designs, which really is quite different from refactoring bad code.

Keynotes

K3 Lean UX: Turn User Experience Design Inside Out

Jeff Patton, Jeff Patton & Associates

Thu, 06/11/2015 - 8:30am

It’s usually the finer points of the user experience (UX) design that separate good-enough software from really-great software. For companies launching new products or adding new capabilities, how well they understand their users and their needs differentiates the wild successes from the dismal failures. This is user experience design, and doing it well in the past took experienced specialists and lots of time. But the world has changed. Jeff Patton describes how Lean UX turns product design into a team sport in which everyone participates. Learn how Lean UX thinking breaks what we thought were good design rules. In Lean UX design, it’s OK to guess. It's OK for developers to talk to users. It’s OK for bad artists to design user interfaces. And, it’s OK to demonstrate half-baked ideas. You’d think that if we break all these rules, good user experience couldn’t possibly result—but it does. Jeff shares examples of how all this rule breaking is supported by a culture of experimentation and learning—and that makes all the difference.