I’m Doing it Wrong? Really?

I chafe at how freely many of us will say you’re doing it wrong.

Sometimes distinguishing a right way from a wrong way is easy. Sometimes it’s not.

Holding a telephone handset upside down appears laughably wrong – unless you’re doing a comedy bit (where it might appear laughably right).

The wrong way to produce software is not as obvious as holding a telephone handset upside down.

Producing software involves contextually-dependent variables. We are faced with business constraints, technical hurdles, and inter-personal challenges. Constraints, hurdles, and challenges are situationally-dependent. Constraints, hurdles, and challenges vary from product to product, and change from one environment to the next.

What might have seemed wildly right in one context, might be wildly wrong in another.

Your Dogma Ran Over Your Karma

A post was shared on agile .net practitioners with the title “If you are building applications without writing your tests first then you are doing it wrong. The title was probably meant to attract attention, and the post was probably written in the vein of self-promotion, but it got my attention.

I have benefited from the virtues of Test First, but the statement, “If you are building applications without writing your tests first then you are doing it wrong” seems hyperbolic, naive and unnecessarily dogmatic.

Situational Utility

Test-Driven Development (TDD) and Test-First have become catchphrases. Who hasn’t been endorsed for TDD on their LinkedIn profile?

Several developers I know use Test First exclusively. Many more developers I know talk about Test First, but do Test After. Still more developers I know appreciate and espouse the virtues of Test-Driven Development, but rarely use it. Hardly anyone doesn’t, at least, pay lip service to TDD.

Developers encounter many different situations. It follows that there are many ways to approach the tasks at hand. TDD is not the holy grail.

Craftsmanship Surcharge

There is at least one situation, and perhaps several more, where TDD or Test First adds a gratuitous craftsmanship surcharge to the bill.

Lets say you are contracted by a start-up to iterate from an initial proposition to a viable business model. Is TDD a cost-saving approach? Probably not. While the code might be flawless, TDD slows down the cycle of testing a business proposition thereby increasing the start-up’s burn rate. Many start-ups don’t need flawless code during the market testing phase. The reality is that there is going to be throw-away code, particularly in the context of a lean start-up where the team is meant to be in iterative learning mode.

Be Kind, Rewind

Several of the useful things many of us picked up in the early days of XP, and during the maturation of Agile, are too often applied as blunt instruments to pummel our less dogmatic teammates.

TDD can be a blunt instrument. Just like the common misapplication of Stand-ups, Retros, and Burn-down charts, Test First can degrade to an abrasive command-and-control directive as readily as it can prove to be a prudent practice.

The What and The Why

Approaches, practices and tools have a place when they serve The What and The Why. We agree craftsmanship deserves attention. As practitioners we love bullet-proof code. Many of us have gotten proficient at The How and The When.

I’m self-critical. I know I might be doing it wrong. In many cases, I presume to be wrong. But increasingly I don’t care so much for The How or The When.

I’m reviving my old mantra: Don’t Lose Sight of The What and The Why.

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.