The Building Blocks of Software Pleasure

I found Aarron Walter’s software pleasure pyramid in Esther Derby’s post Are We Aiming Too Low? Aarron’s sketch is compelling for its simplicity, and for what it says about past and future agile software development.

Software Pleasure Pyramid

David Hussman pointed out that ancient Egyptians practiced evolutionary design with improvements with each iteration.

“The first pyramids were merely burial mounds. The next version was the step pyramid (Djoser’s tomb) and the next version the “bent” pyramid (a design in rock that they had to refactor during construction. These were all the forerunners to the Giza structures. It was a progression of small, simple structures which evolved based on the learning (and failures) from the last iteration.”
~David Hussman

Most of the developers I program with day-to-day concentrate on functional & reliable. And, on balance, we’re proficient, if not rock stars. Many of us have benefited from wisdom from the Agile & XP communities. Most of us use, in one way or another, some or all of the following:

  • granular tasking, 
  • emergent design,
  • programmer’s idioms like One method, One purpose
  • test-driven development, and 
  • continuous integration.

The better craftsmen I have worked with, young coders like Eric Brandes, consider usability as part of the craft and it shows in their work.

I yearn for the pleasurable in software; software that’s a pleasure to use.

Listening to Alan Cooper, the progress to the pleasure plateau is going to require a new level of professional craftsmanship that runs the gamut from simply functional and reliable to sublime user experience.

We are the experts, we are the grownups, and the users are the 5-year old kids. No you don’t give them ice cream & candy but…realize they’re hungry…so you get the broccoli and liver.
~Alan Cooper

We’ve learned from evolutionary science that successful organisms often take advantage of the desires of other species. Apples, in the European-centric frontier of North America, appealed to the human desire for sweetness (and for intoxication in the form of hard cider), so humans cultivated the apple for the properties they desired. Or was it the apple cultivating humans?

Part of achieving the level of pleasurable in our software is to understand human behavior and desires.

How do we get to the pleasure plateau in software?

Like the emergent design that unfolded with the incremental construction of ancient pyramids, the Agile software community continues to learn and grow. Future viability of the community rests on integrating interaction design and adopting some important principles of the Lean Startup community like

Integrating product hypothesis testing into iterative development to create a tighter feedback loop between paying customers and a money-generating (pleasure) applications.

The pyramid is an instructive metaphor because software pleasure rests on the stability of the underlying building blocks of functionality, reliability, and usability.

Value Experience Over Features

As a software developer, it requires vigilance to temper my tendency toward joining feature frenzy. Like you, I like to build features.

My lazy inclination is to forget about asking why or how we justify the new-fangled feature that I’m itching to build.

Features represent our bread and butter, but we are also professionals. We want to be proud of our work.

Since

  • our business partners are utterly, in many cases, clueless;
  • we aspire to be better professionals; and
  • we identify with being craftsmen in the best Alan Cooper-ian sense,

it’s up to us to

Value experience over products & features.

How-To Value Experience?

Be an advocate for users. Politely question what’s motivating improvements. Are improvements driven from hard data or the soft notions of some muckity-muck over in operations? Resist your tendency to join the feature frenzy.

Let yourself be dragged kicking and screaming before you contribute to BAD user experience by layering in Over-Featured Confusion.

Over-Featured Confusion

Case in point of Over-Featured Confusion is LinkedIn’s new and improved Discussions feature.

As soon as LinkedIn released its groups concept, I founded two LinkedIn software groups (i.e., the global Agile .Net Practitioners and the local Twin Cities Software Consultants).

Laudably, LinkedIn has steadily rolled out features that have improved our group experience. Until now…

LinkedIn’s new Discussions feature amounts to a ball of confusion. The most glaring improvement is a horizontal slider bar with options to Like, Pass, Comment or More? as a mashup of blog, news and discussion items scroll past (horizontally).

At best, it’s confusing. At worst, it’s unusable.

  • May I Pass on this colossal FAIL by LinkedIn? No.
  • Did my feedback to LinkedIn about this improvement disappear into a black hole? Probably.

LinkedIn replaced simple & serviceable with confusing & dysfunctional.

Considerations

As design luminary Don Norman says

Forget the complaints against complexity; instead, complain about confusion.

Perhaps it’s excusable to transform something complex into something confusing. But it’s inexcusable to transform something simple, like a discussion board, into something confusing.

Google UX researcher Paul Adams says in his presentation Designing Experiences, Not Products

We need to understand how people think, and what motivates them to behave in certain ways. The best way to do this is to design from the outside in. To observe people in their own environment, probing them so that we understand their behavior. This understanding enables us to design things that are meaningful and valuable to people.

Prepare for Informed Improvisation

Software developers, like many mammals, are sheep-like and slow on the uptake.

We spent the better part of a decade celebrating our avoidance of Big Design Up Front (BDUF).

I jumped on the Agile Software Development hay-wagon. It was

  • liberating, 
  • professionally acceptable, and 
  • socially, much cooler,

to be Agile.

Agilists like me eschewed BDUF. Our approach to design was emergentWe programmed on the fly.

Yes we were faster. Yes we delivered.

In some cases we moved software into production more frequently than the Milkman delivered milk.

The question I ruminate over is

Did we deliver lasting value?  

The cows are still grazing, but I for one, contributed to several steaming cow pies in the name of agile software development.

The voices I respect in our community suggest we’re avoiding the fruits of experience design considerations at our peril. Sorry Milkman, but delivery isn’t everything.

Software Delivery is the milk jug, NOT the experience of gulping cold, fresh milk

There are signs our community is moving beyond the ominous clouds of Deliverence – pun intended – toward reasonable preparation & design discovery.

Building Benches
Design is premeditation. It is never an immutable concept. It is never written in stone. Ideally, my premeditations grow with me into active (perhaps subconscious) meditation during execution whether programming or building benches.

Last weekend I built a cedar bench. Much thought was devoted to who would be sitting on the bench BEFORE I cut wood. I considered comfort and aesthetic appeal. I chose a height of 19″ following simulated user acceptance tests. I made a sketch. I thought about the materials in the context of human contact (choosing naturally rot-resistant cedar over treated lumber).

Our golden retrievers Lucy & Libby seem to be turning their noses up at my handiwork, but my family likes it. I had premeditated design considerations, but allowed myself the freedom to adapt on the fly.  

For me, these up-front considerations, design, or call it what you will, are no more than sound preparation.

Sound Preparation

Sound preparation is not the same as BDUF. I prepare to build something with the tacit understanding I will adapt as the unforeseen emerges.

Sound preparation allows for informed improvisation

Like performers, well-prepared programmers are freer to improvise because preparation considers eventualities – not all eventualities, but some. Preparation frees us to be creative without mucking things up, even if all we start with are a few baseline considerations like

  1. Who’s going to use it?
  2. What do they need?
  3. What do they like or dislike most?

I want to be open to discovery. I want time for up-front user research. I want time to respond to user feedback. I want clear and verifiable benchmarks of value. I want enough information about users and benchmarks of value to allow for informed improvisation once the building commences.

Scrum’s Achilles Heel & Where Scratch Meets Itch

Anders Storm, Head of Development and IT at Tekis AB, posted a cogent reminder of all that’s good about Scrum (see Anders’ post Why I Like Scrum! on his blog Product Development).

Scrumbaya (like Kumbaya)

Anders and I share many of the same likes about Scrum. Scrum was my first step into Agile (thanks Markus). I started a jaded curmudgeon (my apologies Markus), but my Scrum-mates revolutionized my thinking. I am grateful to the pioneers of Scrum.

I like Scrum for its humanity, accountability, explicit trust in programmers, and inherent fairness.

Needs Improvement

I have one criticism of Scrum, but it’s a big one…

The Achilles Heel of Scrum is the Product Owner. The Product Owner is a serious flaw in the approach. In my experience, Product Owners operate on notions about what’s most valuable (what’s a high priority), rather than on verifiable data.

The Scrum community applauds itself for its transparent burn-down charts and their inherent “velocity” when what they’re actually transparent about is speed (e.g., because the direction component is sorely missing).

It bears repeating that

It doesn’t matter how fast we deliver, if we deliver junk.

Verifiable Value

Scrum must evolve beyond the concept of a limited user proxy, like Product Owner, then figure out ways to better understand, measure, and verify the user experience.

In almost all cases I can think of,

the people actually using our software is where the scratch meets the itch. 

Our goal, as always, is to produce incremental value. But in this case, it comes via verifiable value (direction) and not just speed.

I am looking for ways to get to Verifiable Value and to limit Seat-of-the-Pants Guesses.

More