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.

Finding the Software Nectar

I have quirks. One has to do with information workers named Jerry.

When I meet a Jerry, I'll insist that this new Jerry suffer the whole Seinfeld sitcom shtick where I, in thinly veiled disgust, say

"Hello Jerry"

and he, on queue, snidely responds to me with

"Hello Newman"

This all started years ago with a Microsoft practice director named Jerry. The shtick with this particular Jerry works well since I've long suspected we don't trust each other.

"You know who you are, Jerry." :-)

This Seinfeld repartee amuses more than embarrasses (although increasingly more Jerrys have never watched the 1990's Seinfeld TV series).

When I find myself enduring an insufferable meeting with Jerrys, my Jerry-tick possesses me like a pesky eye twitch. Every time this Jerry makes a constructive suggestion, I'll respond with

That's gold Jerry, gold!

It's obnoxious, but I'm no Kenny Bania.

I apologize, in advance and in arrears, to Jerrys future and past.

Many agile software teams are burdened with stakeholders and product owners that set direction grounded in whim rather than on hard data. My guess is that most product owners don't possess savant-like industry knowledge.

I've had it with coding to whim.

Should the next step be sarcastically applying That's gold Jerry, gold! across the range of names to software product owners setting direction based on whim?

Many species, like honey bees, must forage optimally to survive. There is too much churn on most agile software projects. Burn-down charts have developers buzzing, but today's programmers are worker bees bewildered by the fog of business whim.

There must be more efficient means to find the nectar.