On Thinking

Daniel Kahneman, in Thinking Fast and Slow, introduces two “systems” of thinking: fast or type 1, and slow or type 2. We don’t actually have two different parts to our brains—but we do have two distinct types of thinking mechanisms, each with their respective strengths and drawbacks.

Fast thinking happens automatically with little or no effort or sense of voluntary control. Quick, what’s your first reaction to this photo?

My immediate visceral reaction: “That dog is ugly! It looks crazed, angry…. scary.”

The dog is Peanut, winner of the 2014 Ugliest Dog contest. His wild hair, bulging eyes and protruding teeth are at odds with his sweet personality. Holly Chandler of Greenville, North Carolina, Peanut’s owner says he was seriously burned as a puppy, resulting in bald patches all over his body. Peanut is healthy now and nothing like my first impression.

In a nutshell, fast thinking is automatic (we do not have to work at it), impulsive (we can’t easily control it) and emotional (once I’ve told you a little about Peanut you probably feel sorry and sad and more positive towards Peanut, despite your initial reaction). Fast thinking draws on our amazing abilities to quickly form associations between related things. When it works well, we easily come to conclusions, draw out inferences, and confidently decide without breaking a sweat.

It’s sweet when your associative memory clicks along in high gear providing ready answers. But fast thinking can be subtly and easily biased. The variety of cognitive biases we have is astonishing.

In contrast, slow or system 2 type thinking requires energy. We get tired when we do a lot of slow thinking. We use slow thinking to reason logically, compute, or, surprisingly, when paying attention to someone speaking to us in a crowded noisy room. Both writing code and writing prose are slow thinking tasks for me. Reasoning about the cause of a bug is too. The fast cycles of strict TDD help some with breaking up the necessary slow thinking into more manageable chunks. For me, deciding what the test should be and how to implement my design ideas are almost always slow thinking tasks. Writing code may or may not be, depending on how familiar I am with the programming language, tool set and design context.

It is too simplistic to say that our brains are wired to be either emotional or logical. We don’t always get to choose which form of thinking we use. Even more interesting is how the two systems interact. Our system 2 constantly monitors our system 1 thoughts, and kicks in when it notices an inconsistency, saying, “Hmm…that doesn’t seem right,” perhaps leading to some conscious system 2 thinking and problem solving.

But as this two-star Amazon reviewer observes, Kahneman’s book doesn’t contain easy-to-digest pop psychology advice for how to be a better thinking being:

“Peace to all…The idea of system 1 and 2 for the brain was the twist. (System 1 is impulsive autopilot, system 2 reflective and analysis oriented)
Other than that, the book is filled with too many experiments that i felt didnt add practical value to me. I was hoping for practical solutions to help make those two systems work together in harmony…the book did NOT deliver that which was disappointing.”

Kahnman won’t fill you with sound-bite sized advice on how to sharpen your thinking. So what can you do now that you are aware of how you think? Are there ways to counteract the bad things about these systems and amplify the good things? I think so.

Since reading Kahnman, I’ve observed how my environment affects my thinking and how my thinking demands shift from task to task. Sometimes fast thinking trips me up because what I assumed made it difficult for me to really see things as they were. I keep working to counteract cognitive biases of my own and those I work with. I’ve become more aware when others don’t react as I expect or aren’t making “logical” decisions. I’ve become more understanding and less impatient.

I am experimenting with ways to support and enhance system 2 thinking in others and myself. I find that I need to carve out a space where I can work without distraction and have enough time to get deeply engaged in a challenging system 2 type task. I am easily distracted by noise or visual stimulation. I also find the Pomodoro technique doesn’t help me get more work done. I don’t have a problem with focus. My problem is knowing when to take a break. And I don’t easily get back on task after a 5 minute break.

Your experience no doubt varies. Our brains don’t work the same way. Let’s continue exploring how our daily work practices enhance our thinking and where we need to take extra care and pay more attention.

Future Commitment

In early April, I spent a fun weekend at Pace University with Allen Wirfs-Brock and Mary Lynn Manns speaking with students of Pace University’s Doctor of Professional Studies in Computing program.

Mary Lynn

Mary Lynn Manns

It was a good opportunity to reconnect with Mary Lynn and to hear about new patterns in her latest book, More Fearless Change: Strategies for Making Your Ideas Happen.

Mary Lynn and Linda Rising have been working on these patterns for over a dozen years. They aren’t finished (curating long-lived patterns is an ongoing task). They continue to collect and write patterns for those who want to initiate, inspire, and sustain change in organizations they are part of or in their personal or professional life.

There isn’t one magic thing to do to institute change. Mary Lynn and Linda advise,

“You are working with humans, often in complex organizations, so results are rarely straightforward and the emergent behavior might be totally unexpected. Therefore, upfront detailed planning is rarely effective. Instead, take one small step toward your goal and see what happens. You will inevitably encounter missteps and failures along the way….uneven progress can be discouraging but may also teach you about the idea, about the organization, and, most of all, about yourself.”

Significant change often includes performing an ongoing series of experiments.

One new pattern (or strategy) in their book is Future Commitment. This one has hooked me many times.

Instead of asking a busy person for immediate help, ask them do something you need later and then wait for them to commit. Don’t worry about trying to get them to agree right away. Be patient. Keep in touch. Provide them regular information that encourages them to become more interested in your change initiative. Don’t be a pest.

Once they agree to help, solidify their commitment by recording the date and sending it in writing (along with gentle reminders so they are kept aware of their commitment). Reminders can be annoying. So include an update of what is happening and how their contribution will fit as part of a reminder. Have an alternate lined up in case that busy person can’t commit. There’s more to this strategy and the psychology behind how people commit (along with 14 other new strategies) in their book.

Like Mary Lynn and Linda, I don’t view change patterns as evil or manipulative. They are simply tools, that once aware of, you can use to engage people and get them to help you make changes.

And so here’s a future commitment if you have an urge to write about your agile experiences: We need experience reports for Agile 2016. Submit a proposal to the Agile Experience Report program. Do it soon. Within the next 30 days.

You don’t have to start writing now, but if you send in a proposal to me, it will grab my attention. Even better, if you are attending Agile 2015, we can also talk over your proposal. We ask that you write up a proposal so you get in the practice of collecting and communicating your thoughts in written form.

You could wait and submit your experience report idea via the Agile conference submission system in November. If you do, your chance of it being selected is limited. The format of the submission system makes it difficult to include details or have an ongoing conversation to sharpen your ideas. This year we had maybe 100 submissions from which we selected 20.

If you wait to submit your proposal via the conference system, it will have to really stand out from the crowd to grab our attention.

Instead, if you submit your proposal to the Agile Experience Program, it will be carefully read as soon as we receive it. If selected, we will work with you throughout the coming year. You don’t have to start writing immediately. You will get help from a shepherd as you write. As soon as you finish, your work will be published on the Agile Alliance website. You will be also invited to present your report at a future Agile conference.

I’m ready to help you write about your experience if you are ready to make a future commitment to writing. It all starts with your proposal.

Can Nudging Help Us Make Better Choices?

Nudging, as popularized by Richard Thaler’s book Nudge, is the idea of making a by-default action the preferred choice so you don’t have to think deeply to make a good decision. However the common definition for nudge as, “a slight or gentle push or jog, especially with the elbow,” gives me reason to pause.

I don’t like being elbowed, even if it is done gently with good intentions.

Does nudging ever work?

At first glance, I was intrigued by the possibility of personally crafting my own nudges. The idea of setting up personal reminders using a service like NudgeMail, seemed promising. While potentially useful, NudgeMail reminders aren’t exactly what Richard Thaler means when he talks about nudging. A Thaler nudge is more like an unobtrusive force that moves you to make a better decision or action without feeling poked or prodded. A nudge isn’t the same as a reminder.

Successful nudges need to be unavoidable attractive shiny attractions that draw you to nearly effortlessly make good decisions or take appropriate action. They are the not prods, nags, or scoldings, either. You can’t be nudged when you are annoyed.

In today’s Oregonian there was an article about the use of electric car charging stations. The idea behind installing publicly accessible recharging stations was to “nudge” more people to buy and drive electric cars. By plunking public charging stations all over the place, the thinking went, people wouldn’t be so concerned about draining their batteries while out and about.

Public charging stations has been in failure in Oregon. Even though placed in public places, chargers are rarely used. Some appear conveniently located (like parking garages in downtown Portland). But many others are located in out of the way places (there’s one at the back end of a shopping mall near in the small town where I live. I’ve never seen a car there). Turns out they were located more as matter of political expediency than common sense or practicality.

Inconveniently, it also takes hours, not minutes, to recharge a car using them. Consequently, people find it cheaper and more convenient to plug in and recharge their cars at home overnight. They don’t need to top off their battery’s charge while working out at the gym. Often people buy electric cars with the intention of using them only for short commuter trips. They don’t need or want public charging stations.

But consider the case of Tesla. Tesla has strategically installed fast-charge station capable of delivering up to 50% battery capacity to their sporty cars in about 20 minutes (roughly 16 times faster than most public charging stations). Tesla wants its customers to feel comfortable driving their electric cars on longer trips. There’s a Tesla recharging station by the Burgerville in Centralia, Washington, halfway between Seattle and Portland. Tesla owners are more likely to travel between Portland and Seattle, a distance of 180 miles, if they can stop for a burger at the healthy, local food-sourced burger joint halfway on their journey and get their battery charged at the same time. Tesla has found the right nudge to encourage longer road trips.

The idea of painless nudges that help us “do the right thing” seems compelling. But isn’t easy to find subtle nudges for behaviors we want to change.

Merely speculating on what might be a good nudge before you implement it can be a bad idea. You need to experiment. I’m not so sure government policy-makers can or do take the time to experiment on the effectiveness of nudges before they implement them. Perhaps they should.

On a personal level, any nudge I put in place has to be cost effective, cheap to set up, and easy to tinker with. For example, buying fresh fruit (for me, anyways) is just the nudge I need to eat fruit instead of more sugary snacks. If you don’t like fresh fruit, this nudge won’t work for you.

Keeping a tab in my browser open to Duolingo, where I’m trying to learn Portuguese, is just enough of a nudge for to keep me to keep at it. I study for a few minutes every day when I need to take a break from work. And Duolingo gently sends me email reminders about keeping up my daily streak. Still relatively new to Duolingo, these reminders aren’t yet annoying. Overtime, I know they will be. I don’t like to be reminded to do what I’m already doing. I just hope they have a way to turn them off.

If motivated, I can be nudged a little. But I’ve got to be in the right mood and it has to be in an appropriate situation and context. If a nudge feels at all like a shove or a poke instead of gentle, painless, helpful guidance, I’m inclined rebel and do the opposite.

A classic example of “nudging” by policy makers is to create incentives (think tax breaks or credits). For example, giving a rebate upon buying energy efficient appliances or solar panels. That nudge has been in place for some time here in Oregon. But I haven’t bought a new energy efficient appliance simply to get a tax break. Even if the investment will be paid back in a few years in savings on my electric bill. That nudge was more likely to nudge people moving into a new home instead of someone like me.

A couple of years ago, I recycled an old refrigerator because I happened to stumble upon an extremely attractive nudge when I was searching the Internet for recycling options. I could schedule an appointment online (selecting the day and time from a list of available times) for someone to come to my house, cart away my fridge, and mail me a $50 refund check. I was in the right frame of mind for that nudge. The conveniences plus the small monetary compensation made this a perfect nudge.

But it is oh so easy to resist a nudge when I am at all forced to think even a little. I am a cranky contrarian who doesn’t like pushy nudges. Don’t tell me I have to recycle my used appliances. And don’t give me too many options to choose from, either. But give me a choice.

Nudges should be easy peasy, transparent, painless offerings of ideal options.

If you are a policy maker at your company, you might be able establish a few nudges like providing free bus passes to encourage mass transit use or putting in showers to encourage bicycling to work or exercise.

If you are an agile coach or team leader you can nudge a little, too.

Want to limit the time of a daily standup meeting? Hold it around a whiteboard and have people actually stand up. In my experience, getting comfy around a table makes meetings last longer. But watch out. I know some people who happily spend hours talking at the whiteboard. Every day. They need more than a nudge to keep stand ups brief. This leads some agile coaches to introduce protocols or standard ways of doing things that are demonstrated, and then gently enforced in order to encourage appropriate actions. How I feel about protocols and rituals is the topic for another blog post.

Nudging isn’t social engineering for social engineering’s sake, but with the intent of setting up your environment and context so you want to make the obvious better choice without feeling pressured.

Have you found effective ways to nudge yourself and change you or your team’s habits? If so, I’d like to hear from you.

Why Process Matters

I’ve been working on a talk for Smalltalks 2014 about Discovering Alexander’s Properties in Your Code and Life.

I don’t want it to be an esoteric review of Alexander’s properties.

That won’t satisfy my audience or me.

I want to impart information about how Alexander’s physical properties might translate to properties of our software code as well as illustrate poignant personal examples in the physical world.

But equally important, I want impress upon my audience that process is vital to making lively things (software and physical things). In his, The Process of Creating Life: Nature of Order, Book 2, Alexander states,

“Processes play a more fundamental role in determining the life or death of the building than does the ‘design’.”

Traditionally, building architects hand off their designs as a set of formal drawings for others others to build. Does this remind you of waterfall software development? There isn’t anything inherently wrong with constructing formal architectural drawings…but they never end up reflecting accurately what was built. Due to errors in design, situational decisions based on new discoveries made as things are built, better construction techniques, changing requirements, limitations in tools or materials, a building is never exactly constructed as an architect draws it up.

Builders know that. Good ones exercise their judgment as they make on the spot tactical re-design decisions. Architects who are deeply involved in the building process know that.

Alexander is rather unhappy with how buildings are typically created and suggests that any “living” process (whether it be for building design or software or any other complex process) incorporate the following ten characteristics.

He challenges us software makers to do better, too:

“The way forward in the next decades, towards programs with highly adapted human performance, will be through programs which are generated through unfolding, in some fashion comparable to what I have described for buildings.”

As software designers and implementers we know that nothing is ever built exactly as initially conceived. Not even close. Over the past decade or so we have made significant strides our processes and our tools that enable us to be more effective at adaptively and incrementally building software. My thoughts on some ways we have tackled these characteristics are interspersed in italics, below.

Characteristics of Living Processes

1.Step-by-step adaptive. Small increments with opportunity for feedback and correction.
Incremental delivery, retrospectives, stakeholder reviews
Repetitive incremental design cycles:
Design a little– implement–refactor rework refine–design…
Design/test cycles: Write specifications of behavior, write some code that correctly works according to the specification, test and adapt…
Tests and production code equally valued

2. Whatever the greater whole is always the main focus of attention and the driving force.
Working deployable software, minimally-marketable features

3. The entire process is governed and guided by the formation of living centers (that help each other)
Code with defined boundaries, separate responsibilities, and planned for interconnections

4. Steps take place in a specific sequence to control the unfolding.
We have a rhythm to our work. Whether it is test-first or test-frequent development, conversations with customers to define behavioral “specifications”, or other specific actions. In order to control unfolding we need to understand what we need to build, build it, then refine as we go. And we have tools that let us manage and incrementally build and record our changes.

5. Parts created must become locally unique.
Build the next thing so it fits with and expands the wholeness of what we are building. Consider our options. Refactor and rework our design. Make functions/classes/code cohesive. Bust up things that are too big into smaller elements. Revise.

6. The formation of generic centers is guided by patterns.
We have in mind a high-level software architecture that guides our design and implementation.

7. Congruent with feeling and governed by feeling.
Instead of just making a test pass, see if what you just wrote feels right (or if it feels like an ugly hack). Reflect on how and what we are building. Don’t be merely satisfied with making your code work. How do you feel about what you’ve just built? How do those using your software react to it? How do those who have to maintain and live with your code feel about it?

8. For buildings, the formation of structure is guided by the emergence of an aperiodic grid, which brings coherent geometric order
Software is structured, too…we’ve got to be aware of how we are structuring our code.

9.Oriented by a form language that provides concrete methods of implemented adapted structure through simple combinatory rules
We use accepted “schemas” to create coherent software systems. We have software architecture styles, framework support, and even pattern languages emerging…

10. Oriented by the simplicity transformation, and is pruned steadily
We can consistently refactor and rework our code with the goal of simplifying in order to enable building more functionality. We rebuild to create sustainable software structures. Even if we come back to some old working code and see how to simplify it, we can rework it taking into consideration what we’ve learned in the meantime.

Yet, let’s not be complacent. Agile or Lean or Clean Code or Scrum practices don’t address every process characteristic Alexander mentions. I am not sure that all these characteristics are important for building lively software. Alexander is not a builder of software systems, although he spent a lot of time talking with some pioneers and leaders of the software patterns movement.

Some process ideas of Alexander sound expensive and time consuming. Do we always need to reflect on how we feel about what we code? Sometimes we need to build quickly, not painstakingly. We need to prove its worth, and then refine our software. Our main thought may be on just simply making it work, not how it makes us or others feel. So how do we add liveliness to this quickly fashioned software? What’s a good process for that? Mike Feathers wrote about Working Effectively With Legacy Code, but there is a lot more to consider. Maybe that quickly fashioned software has tests, maybe it doesn’t, maybe some parts have a reasonable structure, and maybe other parts should be tossed.

We often build disposable and hopefully short-lived software. Problems crop up when that code gets rudely hacked to extend its capabilities and live past its expiration date.

There are most likely different processes for creating lively software, based on where you start, where you think you are headed, and how lively it needs to be (not everything needs to be fashioned with such care).

People are continually building new and better tools and libraries. There is a rich and growing ecosystem of innovative open source software. Process matters. I think we have a lot still to learn about building lively software. It is a heady time to be building complex software systems.

Architecture Patterns for the Rest of Us

Recently I have been reading and enjoying Robert Hanmer’s new book, Pattern-Oriented Software Architecture for Dummies. Disclaimer: In the past I have shied away from the books for dummy series, except when I wanted to learn about something clearly out of the realm of my expertise. Even then, just the notion of reading a book for dummies has stopped me from several dummy book purchases. Good grief! I didn’t know what I have been missing.

This book is not theoretical or dry. The prose is a pleasure to read. And it goes into way more depth than you might expect. Instead of simplifying the Patterns of Software Architecture book that is also on my bookshelf, I’d say it adds and complements it with clear explanation of benefits and liabilities of each pattern, step-by-step guides to implementing each architectural pattern and more. As an extra bonus, the first two parts of the book contain some of the clearest writing about what patterns are and how they can be used or discovered that I’ve seen.

I wish Bob Hanmer would write more patterns for the Dummy series. He knows his subject. He has good, solid examples. And he doesn’t insult your intelligence (In contrast, I find that the Head First books are definitely not my cup of tea…I don’t want to play games or have patterns trivialized). Bob has an easy, engaging style of writing. The graphics and illustrations are compelling In fact, I reproduced a couple of the graphics about finding patterns in a lecture, with credit to Bob of course, in a lecture I gave last week to my enterprise application design students.

This is a good book. If you’ve wondered about software architecture patterns and styles, read this book. Buy it. And tell your software buddies about it, too.

Domain-Driven Design Applied

Vaughn Vernon’s new book, Implementing Domain-Driven Design, is full of advice for those who want to apply design principles and patterns to implementing rich domain model applications.

Check out my interview with Vaughn for InformIT. We discuss why he wrote this book and some important new Domain-Driven Design patterns and their architectural impact.

There is much to learn about good design of complex software from this book. In future blog posts I plan to unpack some of the meatier domain-driven design concepts and reflect on how best to apply them to designing enterprise applications.

Working–share your experience

One of my all time favorite books is Studs Terkel’s Working. In it, he captured people talking about what they do and how they feel about it. People tell amazing stories about hard work. The book is about, “ulcers as well as accidents, about shouting matches as well as fistfights, about nervous breakdowns as well as kicking the dog around.” I hope you don’t find software development so grim (I don’t ). But maybe you have an intriguing story to tell.

OOPSLA is soliciting Practitioner Reports. The submission deadline is just a short time away–March 19th. If you submit a report and it is accepted, Ralph Johnson or one on his committee will help you tell your story. There are many more interesting stories to be told and if you have one, please consider telling it at OOPSLA. Last year there was a really great story about how software objects finally made it to space in a JPL satellite through the persistence of a guy who really, really believed in the benefits of oo programming. A grad student at Portland State presented his experience exploring Traits–when he was an undergrad. I remember another report where a developer recounted his use of refactoring tools to write transformation rules to transmogrify a massive Smalltalk legacy application’s database access layer. And I recall another telling how a framework for scientific applications evolved. There are always interesting stories to tell; and OOPSLA is a place where you can tell them, whether they be about your latest adventures with web services, domain-driven design, aspects, agile or open source development, or the challenges of developing applications in distributed teams.

Martin Fowler is no Kent Beck

I know the difference between those two….When authors make mistakes, readers notice. In my latest IEEE Software Design Column, Driven…to Discovering Your Design Values, I quoted Martin Fowler as claiming that test-driven development,

“gives you this sense of keeping just one ball in the air at once, so you can concentrate on that ball properly and do a really good job with it.”

Kent quoted Martin in his book Test Driven Development by Example.
It gets a little tricky when you cite someone quoting someone else. Originally, I had the reference to the book in line with the quote attributed to Martin (but my citation only listed the book title, not the author). My editor moved that citation to the back of my article and undstandably filled in Martin as the author. Easy mistake to make and I didn’t double check the references when it was refactored. I assumed my editor would fill in the author appropriately and double check citation.

My fault. You heard it from me first. When anything is refactored, whether it is code or citations or comments, you need to check twice. Since I don’t have an xUnit tool to write tests for citations and quotations, this has to be by visual inspection. I’ll know better next time. Thanks Mirko and Shinobu for caring enough to email me about this mistake.

Translating Object Design

Recently I received a copy of the Chinese translation of my book, Object Design: Roles, Responsibilties and Collaborations. It took nearly three years to translate. I hope it sells well, although authors only get a mere pittance for selling translation rights (think $100 or less–and I have to split that with my co-author). So I won’t be making money even if becines a best seller in China. Creating and marketing a best selling book can be dicey as this interesting blog posting for someone in the book publishing business points out (I didn’t write this book to retire on, I wrote it to get the word out about role-based object design).

I found it fascinating to compare the English with the Chinese edition. As I thumbed through the book several features were missing that we thought essential when we originally worked with our editor (in hindsight, our requests added to the book’s cost, but probably made little difference in how well it has sold). We convinced our editor to produce a two-color book so we could annotate drawings using blue. The editors then figured out ways to incorporate blue into subsection titles, boxed in examples, etc. The Chinese edition was black and white and had no index. Margin comments had been boxed off and inserted along with the main text. That certainly made formatting a lot easier.

It was interesting to see the text sprinkled with English words and pseudo-English class names: e.g. Rebecca Wirfs-Brock, Brian Wilkerson, Rational Unified Process, Kay, GuessingLettersOnly, aMessageBuilder,Michael Jackson (the UK problem frames inventor, not THE singer). The format of the Chinese edition numbered subsections, where in the English language version we did not. On the cover, our names were in a smaller font than the text, forewards by Ivar Jacobson and John Vlissides. I’m guessing this was to sell more books. The cover included the same cover art but the lettering and colors were much simpler. On the cover, the book’s title was in both Chinese and English. The paper is thin decreasing the thickness of the book by 50%. Printing quality wasn’t great. The translated book was 313 pages vs. 390 for the English version. I wonder whether Chinese writing is more compact or whether parts have been omitted. It is hard to tell.

I’m meeting with one of the translators of our book to Japanese at next week’s Architecture and Design World. I really look forward to meeting him in person. Translators who take their job seriously ponder words and meanings. And because of the differences of words in different languages, they can uncover nuances than I ever thought about. For example, I received this query from the Japanese translator about this sentence from our book: “As we conceive our design, we must constantly consider each object’s value to its immediate neighborhood.” He asked, “Does the meaning of neighborhood in your book correspond to the definition ‘objects who live near one another’ or ‘in a particular district or area’? If your answer is yes, could you make selection between ‘live near one another’ or ‘in a particular district or area’ because we have different Japanese words for each.”

One of my favorite books is Douglas Hofstadter’s Le Ton Beau De Marot: In Praise of the Music of Language. This book is all about the nuances of translation. Hofstadter, who also wrote the best-selling Gödel, Escher, Bach: An Eternal Golden Braid, explores the myriad constraints that must be chosen to be relaxed (or tightened) when translating, as well as the choices the translator makes to preserve the original author’s context or to translate it to a more familiar one of the reader. As a vehicle to explore these ideas, he used a 500 year old French poem that he gave to many friends and colleagues to translate (and he, himself wrote dozens of translations). It’s fascinating reading. As a designer and requirements analyst, I often find myself discriminating very fine shades of meaning. There’s nothing straightforward or mechanical about this process. But to me, translating poetry seems much more challenging. And translators of technical books deserve credit and recognition for their own contributions.

Can you really estimate complexity with use cases?

I visited with some folks last week who failed to get as much leverage from writing use cases as they’d hoped. In the spirit of being more agile, at the same time they adopted use cases, they also streamlined their other traditional development practices. So they didn’t gather and analyze other requirements as thoroughly as they had in the past. Their use cases were high level (sometimes these are called essential use cases) and lacked technical details or detailed descriptions of process variations or complex information that needed to be managed by the system. But their problem domain is complex and varied, prickly, and downright difficult to implement in a straightforward way (and use cases written at this level of detail failed to reveal this complexity). Because of the level of detail, they found it difficult to use these use cases to estimate the work involved to implement them. In short, these use cases didn’t live up to their expectations.

Were these folks hoodwinked by use case zealots with an agile bent? In Writing Effective Use Cases, Alistair Cockburn illustrates a “hub-and-spoke” model of requirements. A figure in his book puts use cases in the center of a “requirements wheel” with other requirements being spokes. Cockburn states that, “people seem to consider use cases to be the central element of the requirements or even the central element of the project’s development process.”

Putting use cases in the center of all requirements can lull folks into believing that if they have limited time (or if they are trying to “go agile”) they’ll get a bigger payoff by only focusing on the center. And indeed, if you adopt this view of “use cases as center”, it’s easy to discount other requirements perspectives as being less important. If you only have so much time, why not focus on the center and hope the rest will somehow fall into place? If you’re adopting agile practices, why not rely upon open communications between customers (or product owners or analysts) and the development team to fill in the details? Isn’t this enough? Maybe, maybe not. Don’t expect to get early accurate estimates by looking only at essential use cases. You’d be just as well off reading tea leaves.

Cockburn proposes that, “use cases create value when they are named as user goals and collected into a list that announces what the system will do, revealing the scope of a system and its purpose.” He goes on to state that, “an initial list of goals will be examined by user representatives, executives, expert developers, and project managers, who will estimate the cost and complexity of the system starting from it.” But if the real complexities aren’t revealed by essential use cases, naive estimates based on them are bound to be inaccurate. The fault isn’t with use cases. It’s in the hidden complexity (or perhaps naive optimism or dismissal of suspected complexity). A lot of special case handling and a deep, complex information model makes high-level use cases descriptions a deceptive tool for estimation. That is unless everyone on the project team is brutally honest about them as just being a touchpoint for further discussion and investigation. If the devil is in the details, the only way to make reasonable estimates is to figure out some of those details and then extrapolate estimates based on what is found. So domain experts that know those details had better be involved in estimating complexity. And if technical details are going introduce complexity, estimates that don’t take those into account will also be flawed. Realistically, better estimates can be had if you implement a few core use cases (those that are mutually agreed upon as being representative and prove out the complexities of the system) and extrapolate from there. But if details aren’t explained or if you don’t perform some prototyping in order to make better estimates, you won’t discover the real complexities until you are further along in development.

I’m sure there are other reasons for their disappointment with use cases but one big reason was a misguided belief that high-level use cases provide answers instead of just being a good vehicle for exploring and integrating other requirements. In my view, use cases can certainly link to other requirements, but they just represent a usage view of a system. One important requirement for many systems, but not the only one. If they are a center, they are just one of many “centers” and sources of requirements.