Presentations

In the USA, to legally purchase alcohol, you must be over the age of 21. On some websites, before proceeding, the user is asked, “Are you 21 or older?” If they answer in the affirmative, they can proceed. But is that truly a rigorous design? Of course not! It’s rigor theater. We can lull ourselves in believing we’ve designed sufficiently rigorous systems when we have not. We can cause unexpected behaviors when we enforce rigor and it is too constraining.

Design and modeling rigor is desired when a precise, exact, definitive answer to a question should determine and constrain future actions. Rigor isn’t arbitrary when our software deals with physical laws, or physics and mathematical formulas. But it often seems arbitrary with other system behaviors. When do we need strict precision in answers? When is it a bad idea to enforce precision? What should we do when it’s too hard to enforce seemingly necessary rigor? Those are some questions we’ll explore in this talk.

With experience, we learn to nudge our designs in directions we want them to go, using patterns along with countless (unnamed) personal design heuristics. Our perception of our current design context, as well as personal preferences and design values, lead us to apply particular heuristics and choose a course of action. When learning about any new software design patterns, techniques or heuristics, we view them through the unique lens of their past experiences. And we implicitly add and enrich any new design technique or practice based on our existing design umwelt. Umwelt, from the German, means "environment" or "surroundings” and includes our perceptions of the world as well as our actions to produce a desired effect or change. Our umwelt isn’t static; we reshape our umwelt as we interact with our world, gaining skills and learning to perceive differently. It is our umwelt that both drives and limits our potential actions.

One way to learn how to exercise judgment, develop discernment, and stretch our design umwelt is to perform structured experiments. In this hands-on session, we’ll start off sharing some of our cherished design and testing heuristics and practices. We’ll speculate on some of the “whys” behind why some of our favored heuristics work the way they do. And we’ll practicing picking up subtle cues from our design contexts that may lead us to either apply adapt specific heuristics, discard them as not fitting our current design context, or to seek out new ones.

Models, whether for a software system, a development process, diseases, political systems, or otherwise, are a way to look at (a part of) the world. They make a choice about what is important, what categories we classify things in, what we see, what’s invisible, what’s valued, or even what’s valid. They are reductionist, that is, they only show a selection of the subject they’re describing. And they are biased: They implicitly reflect the assumptions, constraints, and values of the model’s author.

Most of the time, when you adopt a model created by someone else, you assimilate it into your worldview without much thought. You acquire a new way of seeing something. But when you do that, you may not understand the model’s limitations.

You can choose to look at someone’s model more intentionally. You can critically assess whether this model fits your needs. If you’re looking at a model for the first time, you can use that fresh perspective to see what the model includes and what it leaves out. Models are a powerful lens for perceiving a subject, and we should be deliberate when wielding them. This talk gives you tools for critically evaluating any models that come your way.

Elephants are an observable phenomenon, a pattern in nature. Software patterns are observable phenomena of design solutions. Many different descriptions, representations, and accounts of elephants exist. And many people claim to know what an elephant is. Yet they actually have little or limited knowledge of them. This analogy helps to understand how at the same time we both know and do not know what a thing is. This talk will explore the dilemma faced by patterns authors: What to include in a pattern and what to leave out? We also show how experienced designers unfold and generate new solutions based on pre-existing design knowhow and the central role personal design heuristics play in the design process. As this folding and unfolding of information and knowledge seems to be quite an abstract concept, we will choose to make our case by discussing elephants.

Over time, we build up a personal toolkit of design heuristics. I’m been designing software for many years and I’ve seen many alternative design solution solutions that work, so I am hesitant to say any one is “best.” Yet I have my own style and distinct design preferences I have accumulated over years of experience. You do as well. This talk will share a few design and modeling heuristics that were distilled during our pre-conference workshop and reflect on the difference between what works in theory and what we see in practice. And it will challenge you to grow as a designer by becoming more aware of your personal design heuristics and how they are shaped and evolve. You can grow as a designer by examining and reflecting on the decisions you make and their impacts, becoming more aware of seemingly minor decisions that were more important than you thought, and putting your own spin on the advice of experts.

The ouroboros (οὐροβόρος in the original Greek) is an image or archetype of a serpent shaped into a circle, clinging to or devouring its own tail in an endless cycle of self-destruction, self-creation, and self-renewal. Becoming a good software designer sometimes feels like that.

Over time, we consciously and unconsciously build up our personal toolkit of design heuristics. Because I’ve seen so many workable solutions, I am hesitant to say any one is “best.” Yet, some are aesthetically more pleasing to me. I have my own style and distinct design preferences because of my background, that is, the collected set of heuristics and experiences I have assimilated. To grow as designers, we need to do more than simply design and implement working software. We need to examine and reflect on our work, put our own spin on the advice of experts, and continue to learn better ways of designing.

Complex software always has an architecture, even if it isn’t intentional. But being agile isn’t enough to enough guarantee a sustainable architecture. It isn’t prudent to just keep your code clean and hope that good architecture will just emerge. Especially when there is a lot of technical risk, interdependencies, and conflicting priorities. Good architecture requires ongoing attention and stewardship. This talk presents several techniques and architectural activities that are useful on agile projects and explains how an agile architect’s role can and should differ from that of a traditional software architect.

Complex software always has an architecture, even if it isn’t intentional. But being agile isn’t enough to enough guarantee a sustainable architecture. It isn’t prudent to just keep your code clean and hope that good architecture will just emerge. Especially when there is a lot of technical risk, interdependencies, and conflicting priorities. Good architecture requires ongoing attention and stewardship. This talk presents several techniques and architectural activities that are useful on agile projects and explains how an agile architect’s role can and should differ from that of a traditional software architect.

As team leaders or architects, we can benefit from knowing more about how we think, deliberate, and decide. Thinking, Fast and Slow, by Daniel Kahneman, explains two systems that drive how we think. System 1 thinking is fast, intuitive, and emotional; System 2 is slow, deliberate, and logical.

In this session, you will learn how fast and slow thinking affects your decision making. You’ll explore how common development practices, with an emphasis on agile practices, can amplify your thinking abilities and how they might lead you astray. For example, Given-When-Then behavior-driven development (BDD) scenarios are concrete and specific. They prevent us from leaping to conclusions about expected results. Those same BDD specs can also lead you to believe that’s all there is. The Pomodoro Technique helps block work into manageable chunks, making time for uninterrupted slow thinking. But what else might you do?

Fast thinking works well in familiar contexts. You save time when you don’t have to deliberate over details to make informed decisions. But fast thinking can lead to poor decisions. You might jump to conclusions, be wildly optimistic, or under-assess risks and rewards. You need to exploit both fast and slow thinking on agile projects. And you need to be aware of when fast thinking is tripping you up.

During this session, you will explore some impacts of fast and slow thinking and share where you might need to slow down or speed up. You will practice reframing questions about specific situations in terms of fast and slow thinking. And you’ll identify specific situations where your thinking needs to shift and explore how to make those shifts.

The rhythm of agile software development is to always be working on the next known, small batch of work. Is there a place for software architecture in this style of development? Some people think that software architecture should simply emerge and doesn't require ongoing attention. But it isn't always prudent to let the software architecture emerge at the speed of the next iteration. Complex software systems have lots of moving parts, dependencies, challenges, and unknowns. Counting on the software architecture to spontaneously emerge without any planning or architectural investigation is at best risky.

So how should architecting be done on agile projects? It varies from project to project. But there are effective techniques for incorporating architectural activities into agile projects. This talk explains how architecture can be done on agile projects and what an agile architect does.

Complex software always has an architecture, even if it isn't intentional. Being agile isn't enough. It isn't prudent to just keep your code clean and hope that good architecture will simply emerge. Especially when there is a lot of technical risk, interdependencies, and conflicting priorities. Good architecture requires ongoing attention and stewardship. This talk presents several techniques for incorporating architectural activities into complex agile projects and explains how an agile architect's role differs from traditional software architects.