Simple, Assertive Software

Do you want your app to Kick Ass & Call it Love Story? Keep it simple. And make it assertive.

Focus on doing at least one thing right.

Distill that thing to its essence. Industrial designer Dieter Rams advises, Less, But Better.

Whenever I've ruminated on then distilled an idea - whether in the shop or in the cubicle - the distillation is almost always stronger.

Less, but better – because it concentrates on the essential aspects, and the products are not burdened with non-essentials. Back to purity, back to simplicity.
— Dieter Rams, 10 Principles of “Good Design”

Twitter is an example of not overstepping a founding concept of a 140-character micro-blog, then focusing on delivering essentials. Simple idea. Simple execution.

I have grown weary of feature-driven apps. In particular, I am weary of apps that try to be everything to everybody — more so when they miss the mark on the essentials.

Assertive Over Universal

Microsoft Word is the universal remote of application software. It's a work-horse I use almost every day because, as luck would have it, I can efficiently produce documents with it. But I'll be damned if I know what many of the icons signify on the toolbar.

Microsoft Word 2010 Toolbar

Despite a bewildering quiver of options, settings, and features, Word delivers on the essential. If you provide users with a gazillion options, settings, and features, be sure to have the empathy to deliver the essential.

For developers, Nice to Have is the front door of feature-madness. Nice to Have is often a one-way ticket to frustrating software.

The most pleasurable software often seems to have an ax to grind. In the most pleasurable cases, it's a sharp ax. Should your app take sides? The folks at 37Signals think so. I suggest reading their essay Make Opinionated Software. Jason Fried, and others, make the case for assertive software:

The best software has a vision. The best software takes sides. When someone uses software, they're not just looking for features, they're looking for an approach. They're looking for a vision. Decide what your vision is and run with it.

A shining example of assertive software is Ayende Rahien's open-source Document Database RavenDB.

When I set out to build RavenDB, I had a very clear idea about what I wanted to do. I wanted to build an integrated, opinionated, solution. Something that will do the right thing most of the time, and let you override that if you really want to.
— Ayende Rahien

RavenDB is good at one thing - providing lightening fast read-models developers can bind to views. And to my good fortune, Ayende imbued RavenDB with guiding opinions - opinions that rescue us from sloppy coding. For example, RavenDB expresses an opinion about unbounded result sets. RavenDB will let you query for the mother lode, but forces you to override default behavior.

Ayende has well-considered professional opinions and expresses them in his software.

So my new mantra is this:

Keep it simple. Make it assertive.

REFERENCES

• Getting Real: The smarter, faster, easier way to build a successful web application, Jason Fried, et. al., 2009.
• RavenDB in a Nutshell.

YSOD is the New BSOD

Old Paradigm

New Paradigm

In the enchanted land of Microsoft Windows OS and Microsoft IIS, the Yellow Screen of Death (YSOD) has all but replaced the Blue Screen of Death (BSOD).

This phenomena is a resplendently chromatic illustration of a Bobtuse principle:

Nothing in the universe is static or perfect.

Should Designers Code?

Bobtuse Honeybee Pagoda

I am an long-time programmer. I have a keen interest in simple design and providing a pleasurable aesthetic experience in most things I build.

Jon Kolko's post code is material: why designers must learn to code got me thinking, and predicting:

Designers don't need to learn to code. The code will come to them.

My Programming Arc

I wrote my Hello World in FORTRAN at the University of Minnesota in the early 1980s. But I started programming in earnest as a Civil Engineering undergraduate in the mid 1980s in the days when fast was turbo.

Today I am handsomely compensated to jerk around coughed up hair balls of client-side JavaScript.

Thankfully I never had to program in machine code. One great programming leap was the advent of commonly used computer languages like FORTRAN that abstracted the complexities of machine code.

Another Great Leap

Alan Cooper in his office
at Cooper in San Francisco

Programming made a quantum leap when Visual Basic 1.0 was introduced in 1991. Visual Basic pioneered drag and drop design for crafting user interfaces.

Visual Basic derived from a form generator prototype developed by Alan Cooper and his company called Tripod.

Alan Cooper put the "visual" in Visual Basic

The visual nature of the new Visual Basic paradigm abstracted the software maker from the underlying sausage.

The Visual Basic leap for occurred after the 1991 COMDEX/Windows trade show. There have been no equivalent leaps since. We're overdue.

The Next Great Leap - A Future for Creatives

Returning to my assertion that

Designers don't need to learn to code. The code will come to them.

I suspect there will be a bright future for creative types. All that's needed is another revolutionary leap in development tooling that will enable designers to do what programmers do without having to know how to code. Someone will abstract the complexity.

The explosion of rich client applications, and all of the attending JavaScript schmutz, is a programming nightmare for cats like me who have known better times.

Today's rich client frameworks and persistence schemes have lots of hoop-jumping complications.

 Too much sausage meat! 

Take heart, I think tooling will be invented that will put the sausage back in the case.

It is laudable to know the your work environment and the materials you work with through and through. But in the case of making applications, simplification by abstraction is what frees us to be creative.

Already tools are appearing that enable applications to be built without the gratuitous and frustrating hair balls that require the services of a programmer.

So I think the code will come to the designers. Application development will be made visual, gestural, instinctual and intuitive.

Say No to Brogrammers

I have observed a disturbing trend in software circles where cocky, mean-spirited brogrammers infect development teams. Urban Dictionary defines brogrammer as:

1.	brogrammer	151 up, 47 down
	A programmer who breaks the usual expectations of quiet nerdiness and opts instead for the usual trappings of a frat-boy: popped collars, bad beer, and calling everybody "bro". Despised by everyone, especially other programmers. Oh my god, John is talking about football and chicks again. That guy is such a brogrammer. programmer frat boy bro douchebag developer by seldo Dec 2, 2010

I find the brogrammer vibe toxic for several reasons:

1. Fun dies
• Teammates dread coming to work.
• Team outings become an insufferable chore.
• Teammates can no longer laugh at themselves.
2. Innovation suffers
• Teammates fear hazing.
• Teammates are afraid to speak up.
• Teammates are afraid to fail.
• Teammates are afraid to try something new.
3. Productivity suffers
• Teammates are not forthcoming. As such, disingenuous Iteration Retrospectives stifle self-correction.
• Teammates are fearful of committing code without first performing checks and crosschecks.
• Teammates are fearful of the potential humiliation of breaking the build.
• Teammates are loath to ask questions for fear of retribution.
4. Quality suffers
• Teammates dread pair programming.
• Teammates dread the humiliation of code reviews.
• Teammates avoid questioning or debating a technical approach.
• People-Haters use metrics like code coverage to flog rather than learn.

Two red flag artifacts of the brogrammer vibe are Build Monkeys and Nerf Guns:

1. Build Monkeys - a stuffed animal, or mascot of humiliation, gleefully bestowed upon programmers who break the build (or otherwise defy bro-thoritarian rule).
2. Nerf Guns - toy weaponry gleefully deployed to pelt & punish programmers who inadvertently imperil something as inconsequential as test code coverage.

Nerf wars seemed innocuous when perpetrated by the socially inept smart people we'd all grown comfortable working with on our software teams. But now that the brogrammer boys have entered the fray, the once innocuous joviality has morphed into mean-spirited team oppression.

"Let's put the pro back in programmer...no more ninjas and definitely no more brogrammers."
~ Daniel Hamlin, 7:33 PM - 25 May 12 Twitter for Mac

I value the people I work with much more than the technology, or the software product we're building. I refuse to engage in this behavior and plan to defy Brothoritarian Rule.

Fear, hatred, and suspicion narrow your mind – compassion opens it.
~ Dalai Lama, 4:27 AM - 30 Apr 12 via Twitter

Additional Reading

• "Gangbang Interviews" and "Bikini Shots": Silicon Valley’s Brogrammer Problem, by Tasneem Raja, Mother Jones, April 26, 2012.
• In tech, some bemoan the rise of 'brogrammer' culture. by Doug Gross, CNN, May 7, 2012.
• In war for talent, 'brogrammers' will be losers, by Gina Trapani, Special to CNN, May 10, 2012.

Agile Anti-Patterns

A few Agile anti-patterns I have experienced as a developer are:

• Business Allowed to be Lazy. A counter-productive friction exists between highly productive developers (held accountable by process metrics) and largely unaccountable business proxies. Often the business proxies abuse the flexibility of discovery in Agile and some use it as an excuse to be lazy or disengaged.

Why are developers asked to estimate a story if the business can't articulate clear acceptance criteria or fail to deliver a simple sketch or wire frame?

• Over-Emphasis on Velocity. Speed is mistaken for velocity. Velocity has two components – speed and direction. I’ve been on teams who were delivering working software iteration after iteration only to find we were building a product that was unusable, inferior, or somehow missed the mark because direction from the business was misguided or lacking. We focused on delivering, not on the product.

When the burn down shows "done" and the business has a product they couldn't use or don't want, it's the business' fault. Because the only way this could happen is that they didn't show up to the demos, didn't ever walk through the lab, didn't talk to anyone building or testing the system. If there was no mechanism to make sure the blame was spread there, this is just pure corporate oncological dysfunction.
~Colonel Nikolai, post comment Oct 28, 2011 08:04AM.

• What to do with Project Managers? Traditional PMs are too often shoe-horned onto Agile teams because the organization can't figure out what else to do with them. Traditional Project Management is an extension of old-school Command & Control that savvy developers can't abide. It is based on hard estimates and Gantt charts. I have observed PMs using Burn-down charts like a blunt instrument to flog developers.

Dear PM,
When you continually ask 'Is it done yet?', the veracity of the answers rapidly degrade to pure lip service.

• Process Over Pragmatism. Teams often feel compelled to follow process for process sake or because it's been decreed by the organization. The most effective Agile teams I have been on discovered what worked in the prevailing conditions. There is no one-size fits all.

Dear Process Cop,
Developers welcome process when it makes sense, but gratuitous ceremony is a waste of everyone's time.

• Standup as Status Update. Standup meetings seem to have devolved from the imagined intent to be informative and consequential to tedious status updates.

Dear Teammate,
If you don't have something wildly informative or marginally consequential to say, please cede your turn. Standup is not CYA.

Do these seem familiar? Which anti-patterns have I missed? I welcome your feedback.

Design Quest - Interaction Design Day #1

Day One of Cooper's Interaction Design Practicum had many highlights. Some of the topics covered includes the following ideas, practices & tips:

• Design Is - Groundwork Definitions
• Synthesizers and Generators 
• Pretend It's Magic
• Goal-Directed Design
• Alan Cooper Q&A
• User Interviews - Guidance & Tips

Design Is...

Cooper managing director of interaction design Doug Lemoine was our practicum leader. Doug established groundwork design definitions.

Design is the conscious and intuitive effort to impose meaningful order.
~ Victor Papanek, Design for the Real World: Human Ecology and Social Change

Good design ensures usefulness. The web-based file hosing service Dropbox is useful. The Segway Personal Transporter, not so much.

Humorous snark about the perceived need and Segway price point from fellow-attendee Matthew:

I wish I had 10 grand to make me even lazier.

In a well-executed design, people delight in simple, intuitive interactions


Synthesizers and Generators

It has been said that Cooper's secret sauce is to work in design pairs. Cooper pairs consist of a Generator and a Synthesizer. The Generator leads concept creation,while the Synthesizer leads narrative creation.

Generator	Synthesizer
Good at visualizing systems Versed in usability & IxD principles Responsible for screen sketches	Good at narrative, facilitation, and detail Versed in communication and process Responsible for documenting Research & Development

Cooper's paired design balances generative thinking (what could the product do) and evaluative thinking (what should the product do).

Pretend It's Magic

One pitfall is thinking about what the system can do at the expense of what the system should do. Edward de Bono's Lateral Thinking was presented as a problem-solving technique that uses an indirect, creative approach. Problem solving can follow a practical path, or a magical path (shown below). Often considering the ridiculous, the ludicrous, and the impossible -- the magical path -- leads to a great idea.

Sometimes a product vision is blurred by a natural tendency to focus on product implementation. That's when it is time to switch off our internal editor and pretend it's magic (e.g., what would a magical device do) or pretend the product is human (e.g., what would a human assistant do?)

Goal-Directed Design

Goal-Directed Design considers what should be built before starting to build it. Cooper has observed that goals are stable targets. The supporting example is a cross-country trip. The goals of cross-country trip, whether in 1850 or today, are the same. Cross-country travelers want get there as soon as possible, be as comfortable as possible, and travel safely.

Context, tasks, needs and tools change, but the goal remains the same. For example, air travel can be non-stop where one needs something to read for 5 hours, whereas stage coach travel had 20 stops where one needed something to read for 22 days. With air travel one wants to clear airport security, whereas with stage coach travel one had to be sure to bring a firearm.

A visualization of Cooper's Goal-Directed Design appeared to be a DNA chain with the following elements:

• Research - Understanding business and user's needs.
• Modeling - Digest the research and build consensus among stakeholders and project team. Modeling of personas and modeling scenarios.
• Requirements Definition - Define the product experience (i.e., key user goals, functional needs, and emotional needs). Looking for the sweet spot of business goals, user needs, and technical constraints.
• Framework Definition -A holistic view of the design using scenarios as the foundation. Focus on most appropriate concept.
• Detailed Design - Design the product in enough detail to prove feasibility. Collaborate with engineers to ensure feasibility.
• Implementation Support - Ensure the product is built as intended. Advocate and build empathy for the user.

Rinse and repeat!  The process is iterative

Alan Cooper Q&A 

Alan Cooper entertained questions in the afternoon. One of several things Alan said that resonated with the audience involved the conventional title of Software Architect. Cooper feels Software Architect is a misappropriated of term. The role of an interaction designer is more akin to the title Software Architect.

An architect is a person at the nexus of people, purpose, and technology -- not someone working in isolation close to the metal. ~Alan Cooper

User Interviews

User interviews are one of the primary methods of acquiring intelligence for the product design. Two approaches found to work are:

1. One-on-One Interviews - looking for an understanding of user motivations, biases, and concerns;
2. Conduct Workshops - looking at multiple stakeholders thinking creatively and moving toward a shared vision of the product.

Some fundamental questions discussed for an effective interview:

• What's your role?
• What are the benefits for the business? For you?
• How will it make money?
• How do you define success?

Snapshots

View of Bay Bridge from Cooper Reception

Alan Cooper signing my copies of his books

Design Quest - Day Zero

Priming for Cooper's Interaction Design Practicum, I visited Less and More - The Design Ethos of Dieter Rams at SFMOMA.

Dieter Rams is a German industrial designer whose body of work is associated with and in many ways emblematic of the Functionalist, Minimalist and International schools of design where pure aesthetic considerations are consciously subordinated to the object's function and the ergonomics of its use. Remember those sleek Braun consumer products? That's Dieter Rams.

Rams' imperative is that

The form of an object should follow its function.

His work is characterized by:

• Aesthetic Restraint - Less but better.
• Moral Dimension - He advocated for sustainability before the word was coined.
• High Quality Manufacturing - Materials, Fit and Finish.

Consider Rams' ten principles of "good design". My favorite of Rams' principles are

• Good design makes a product understandable (#4); and
• Good design is a little design as possible (#10).

They're my favorites because they cut to the core of what I consider essential aspects - intuitiveness and simplicity.

My aim is to omit everything superfluous so that the essential is shown to the best possible advantage.
~ Dieter Rams

Tomorrow is Cooper's Interaction Design Practicum.

Good design is making something intelligible and memorable. Great design is making something memorable and meaningful.
~ Dieter Rams

Continue to Design Quest - Interaction Design Day #1.