ScreenCasts For Bug Fixes

The Problem

I shouldn't be such a curmudgeonly troll when it comes to software tools that are supposed to make things easier for me. But I am.

• The Agile Tracking software I have used does not make things easier.
• The Bug Tracking software I have used does not make things easier.

Why? Stuff gets missed. Stuff gets lost. People can't consistently write clearly. People can't consistently find things. And, I'm kinda dense.

Red Thread of Failure?

The red thread of failure, and the root of my dissatisfaction is communication, or lack thereof. Communication is munged, obscured and buried in software tracking tools.

We falsely assume because something is written down, that it is also clearly communicated. Not so.

A client said to our software team a few projects ago,

I'll summarize our discussion & queue it up in Brand X.  (Brand X is tracking software) 

I replied,

That's fine, as long as we recognize that Brand X is where critical information goes to die.

If I possessed extraordinary senses (visualize the pinball wizard from the tune by The Who), then perhaps a few cryptic lines buried in an email, or saved in a software tracking tool, would suffice.


But, This Is Easier

The forward-thinking folks at Affinety Solutions found a way to make my programming easier. Affinety founder Steve Holewa contracted me a few years ago to update parts of their software. During a flurry of recent updates, Sys-Ops expert Holly initiated sending links of short videos she had recorded using ScreenCast.com.

Holly's screencasts include narrated screen illustrations of the bugs I have caused and the nice-to-haves she has found in code I have staged for her in QA.

Two of the subtleties I like about Holly's screencasts that simply would not translate from words buried in a software tool:

• See - I can see the sequential steps she took, and the data entry she made, to re-create the bug.
• Hear - I can hear the tone in her voice as she describes an issue to judge emotional cues like urgency or frustration.

Plus, I can replay the clip until I understand the problem.

Sliced Bread

This might not be the Stradivarius of shortening the bug fix cycle, but it might be the sliced bread of subtle cues in communication that enable efficient off-site feedback cycles.

Thanks Holly.

Startup Pivoting & Shadow Beliefs

Startup Pivoting

At the Startup Lessons Learned conference last week, there was much ado about Pivoting. As Alan Cooper says in his post To Pivot, Or Not To Pivot,

When a startup company discards Plan A and moves on to Plan B, it is called a “pivot.”

When I hear Pivot, I recall my physical education teacher screaming at me not to scuff the gym floor with my "street shoes" when I

put my right foot in...
dancing the Hokey-Pokey.

Pivoting for startups is moving incrementally toward something better - a better business model.

Pivoting is like the iterative numerical methods we used in college programming classes. You’d start with a seed value, chunk along for a bit, and then check your convergence. With enough constraints and suitable convergence criteria, convergence was almost guaranteed. Occasionally an anomaly would unravel your code into memory consuming divergence, but hopefully you programmed a check for that condition before you smoked your 256KB.

Shadow Beliefs

Shadow Lines by Abdulla Zaid

One of the things I heard from Startup Lessons Learned conference organizer Eric Ries is the term Shadow Beliefs. These are the closely held (perhaps subconscious), somewhat notional beliefs (and false assumptions) that frequently sink good-intentioned entrepreneurs and insidiously swamp the best agile software teams.

All of us fall somewhere in the continuum of delusion, particularly those under the spell of a great startup idea or a cool software product.

Do we believe we know what the customer wants?

A common shadow belief is

We know what the customer wants. 

Cooper, a digital product and interaction design firm, founded in 1992 by Alan Cooper, is a leader in discovering what users want. Most of us think we know what the customer wants, few of us do.

Do we believe that advancing the plan is progress?

Another shadow belief is

Advancing the plan is progress. 

This is a single-line indictment of dogmatically Agile software teams that harkens back to the Discovery vs. Delivery discussions at Code Freeze 2010: Redesigning Agility. Some time before the Code Freeze conference he organized, 2009 Gordon Pask Award Winner David Hussman tweeted,

If you don't know where you are going, it's easy to iteratively not get there.

This shadow belief is an even bigger pothole for startups than software development teams.

Framing Product Development

Language helps us to frame problems and challenges.

George Lakoff introduced me to how language frames arguments in the political sphere.

Today I attended the DevJam simulcast of the Startup Lessons Learned conference. This global meetup was the brain child of Eric Ries. Eric coined the concept of Minimum Viable Product and is the cheerleader of the lean-startup movement.

Minimum Product

Now I have heard of

• Minimum Viable Product;
• Minimum Desirable Product; and
• Minimum Feasible Product.

It seems all the Minimum Product ideas are hypothesis-driven approaches to product development. That is, with a product hypothesis, or hypotheses, one builds as much as needed to test the product hypotheses.

One of the take-aways I got from Startup Lessons Learned is there are several ways to linguistically frame software product development. Viable, Desirable, and Feasible are Framing words - they frame how we think of our product development.

Andrew Chen, a conference panelist, introduced me to Minimum Desirable Product. Minimum Desirable Product is the simplest experience necessary to prove a high-value, satisfying product experience.

Andrew adds Minimum Feasible Product to the mix, then distinguishes differences between Viable, Desirable, and Feasible.

Viable	think business
Desirable	think user experience
Feasible	think engineering

Desirable hits my sweet spot.

Viable, while helpful, has a air of life support about it. Feasible, also helpful, has a hint of the analysis-paralysis syndrome.

Desirable Resonates

Desirable resonates because it implies an emotional reaction. Emotions spark viral movements. Startups, like viral movements, are predicated on reaching a Gladwellian Tipping Point.

The inventor's challenge is to change minds & behavior.

In Switch, Chip and Dan Heath argue for appealing to The Elephants and The Riders. The emotional side of change is The Elephant. The rational side of change is The Rider. They say,

"The Elephant's hunger for instant gratification is the opposite of the Rider's strength, which is the ability to think long-term, to plan, to think beyond the moment."

Our software products need desirability at their core. They must inspire and appeal to emotions - to satisfy The Elephants in us, but then, over time, they must also provide lasting value - to satisfy The Riders in us.

Start with the goal of desirable. Desirable gets us into the game.

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 emergent. We 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.

Evolutionary Constants & Thingamabobs

A portable Ouija Board, but then what?

The techno-media's yadda-yadda about Apple's iPad reached fever pitch late last week.

The Twitter chatter

...you drove from Vancouver to Seattle, without reservations, and still got an iPad faster than I did!

drove me to my un-follow tipping point.

iPad-as-Serving-Tray

I tagged the iPad-as-Serving-Tray image above with:

gizmo, gadget, contraption, doohickey, thingamabob, and thingamajig. 

I amended my tags to include conspicuous consumption because of the flocks of would-be-kitchen-waste-recyclers camping out and clamoring for tomorrow's disposable consumer electronic device. Tag that with irony, then remember to save your iPad for future tea ceremonies.

If Steve Jobs is really as obsessive about details as Apple lore suggests, why would his product designers choose a form factor whose dimensions 9.56 inches by 7.47 inches don't yield the golden ratio?

Audacious.

1.6180339887

How is it that a shell, or a sunflower seed pod, or a palm leaf spiral evolved over eons to conform to a number like 1.6180339887?

How is it that the proportions in various parts of a dolphin's body incrementally optimize over eons to yields universal evo-constants?

Is it professionally reckless for designers to ignore these evolutionary constants?

Perhaps not. But in my mind, the designer had better have a compelling reason for ignoring time-tested constants found in nature.