I have a problem with the statement that detailed requirement specifications are bad. No, they are not. Not following or not implementing the specifications is bad.

I work as a interaction and interface designer and have seen how not implementing the specification makes the product or a certain feature less usable than intended.

I know that the minor details can make a product feel usable, so I pay attention to such details. Developers, or coders, on the other hand think about things, such as code integrity and performance. The interaction details are beyond their mindset.

A small example. We have a product that allows users to set relations among records (like people and companies). When users want to set a relation to an item, they click a button to open a form where they select the item to relate.

The developer has to open a form. She just opens the form and forgets to put the focus in the first field in the form where users type the name they want (despite the specification). So users have to click in the field first (or tab to it). This does not seem like a big deal; however when users have to do it many times a day, they lose precious seconds that pile up and eat out their productive time.

If we do not have a specification, the testers will not know that not having the focus in the first field is wrong. Since we have the spec, testers file a bug, and the developers fix it.

Do developers learn from the experience? Not necessarily. Remember, their mindset is different. I have seen this particular focus-not-in-the-first-field bug filed several times.

Cheers
Jimmy

I think in software we treat code as sacrosanct, and that a bad implementation represents completed work and therefore would be a waste to throw away, no matter how flawed. We forget however that it is exclusively an artifact of language, and is immediately derived from the mental model of its author. That somebody understands a given problem is infinitely more important than any particular incantation that professes to solve it.

As a practical litmus test, compare software with a legal contract, a piece of music or a diplomat or politician’s speech. In any of these artifacts is it more important that they are right or that they are right now?

VERY interesting observations. They really deserved to be an article unto themselves. Have you contacted the editors of Johnny Holland? This is good stuff.

You touch also on the problem so many of us know: clients frequently mistake a prototype for a finished product. But as Alan Cooper rightly points out, it’s cheaper to throw the prototype code out (which is invariably verbose and poorly structured) and replace it with streamlined code now that the challenges have been sorted out. I’d like to hear more about your thoughts on this, too. But another comment to this post would probably not do them justice.

Warmest regards,
Eric

In preparing for battle, I have always found that plans are useless but planning is indispensable. — Dwight Eisenhower

As we project our expectations farther out into the future, the probability that something will go awry compounds upon itself. One unexpected event will necessarily affect any subsequent activities that depend on a particular result. This causes ripples through the process which multiply in cost at every turn.

The character of software and other creative endeavours is possibly the least forgiving in this regard, since there is no huge capital cost (of factories, materials, logistics, etc.) to act as a centre of financial gravity. In an industrial-age project, the cost of failure is massive, immediate, and enormously conspicuous. In a post-industrial project, failure is silent, as it is merely the absence of success.

I see us approaching a method of production of software and similar artifacts with better than moonshot odds of delivering value. We’ve dispensed largely with prescription in favour of exploration, which is altogether a good move, but I still see two flaws that we have yet to correct.

First, I still see a lot of fixed-bid contracts and permutations thereof. This includes equity financing and internal budget allocations, and people continue to do it even though nobody expects to actually deliver on time or on budget (minus the naïve customer! Or producer for that matter). I think it would benefit us on the whole not to obfuscate these immensely unpredictable (though not necessarily high!) costs and figure out new ways of financing these projects.

Second, principle #1 of the Agile Manifesto is the early and continuous delivery of valuable software. In my (perhaps limited) experience, delivering software early is at best a palliative for eager management types and at worst a permanent commitment to a suboptimal and severely limiting solution.

I should make myself clear: it is imperative that we furnish customers with concrete demonstrations of progress, I just don’t think code is always the best way to do that. I’ll go further by claiming it usually isn’t.

The basis of my claim is that software reduces to an extremely precise incantation of a business process. Consider:

First ask yourself “How would I do this without a computer?” Then have the computer do it the same way. — Mark-Jason Dominus

From a decade of writing code for a living, I can attest that’s pretty much how you do it. Where it gets difficult is in defining what this is. It is important to recognize that software is none other than an artifact of extremely precise language. It is most successful when we can frame it in numerous nesting layers of language that begin broad and fuzzy and successively increase in precision.

Merely paring down, by the way, is a questionable strategy. It mortgages the long term for the short, and is unnecessarily consumptive in its own right. I speak of course of the minimum viable product (that would be Eric Ries). As I remark elsewhere, there is scarcely anything more contradictory to the timely acquisition of valuable results than bickering and vacillating over what work not to do.

To be sure, there is a category of interim deliverable that absolutely must be delivered as software. If we want to answer questions about feasibility, the behaviour of real data in bulk or the fitness of third-party software, we cannot avoid writing code. Where we get into trouble is in delivering something that can be mistaken for the finished product.

I submit that if we started treating software production as a novel and idiosyncratic process, rather than trying to cram it into a paradigm of construction (or manufacturing, or gardening, or rugby, or any other metaphor), we might find even better ways of delivering even higher quality results.

I like the Adaptive Process concept. And I finally fully understand why one of the other players in our professional market, Adaptive Path, chose their name. I always “sort of” got it. But now I think I truly understand.

Don’t get too down on Zero Defects. Things only become frozen when ZD is applied inappropriately and thus discourages feedback and development.

Dave, I was wracking my brain to remember where I had my McDonalds info from. A couple of searches on the internet led me back to my guru, Clayton Christiansen at Harvard. Here’s a link to a 2007 Forbes article that talks about the same stuff:
http://www.forbes.com/2007/08/31/christensen-innovation-mcdonalds-pf-guru_in_cc_0904christensen_inl.html

Dave,I can’t tell you how honored I am that you took the time to write. I had the pleasure of meeting your brother back in the mid-eighties. And the problem you point out with Zero Defects was exactly the point of my message here – watch out for the stupid managers. Although you may think I’m wrong, I agree with pretty much else you say.

I actually discussed this with Philip after he told a group of us (about 1988) that he was so strict in his approach that he didn’t even drink a glass of champagne at his daughter’s wedding. As to Zero Defects, no, I don’t think there is much room for exceptions. But I’ve seen some deplorable implementations, particularly during the quality boom back in 1985-9. And you probably have some good war stories, too.

But you do bring up a fascinating point about the ability to understand what these programs are about. Personally, I get TQM, but balk at House of Quality. And I have been a great promoter of Zero Defects for over a quarter of a century because it is simple to explain, easy to understand, demonstrably beneficial.

By the way, if you have time sometime, I’d love to share some thoughts with you about how creativity and insight CAN improve a production process or service offering. This has nothing to do with Zero Defects, this is about encouraging the front line to give feedback that can improve processes and innovate. And to use your own example, McDonalds, well, the Egg McMuffin, Big Mac, and Happy Meal were all invented by local franchise managers. Food for thought?

Clearly when we are talking about production of physical products there is a benefit in ensuring quality in the sense of producing a higher yield and less product defects. This does however not apply to human interaction or any other human endevaour. Zero defects in business process means that the system is frozen and frozen things are DEAD! No further improvement. The ting that is lost in the process is the human!

I too use the principles of setting out to sea a lot. Being a captain is a lot like being a process owner. You depend on your knowledge, experience and on your team. Only to a limited amount does one depend on rigid procedures. Maybe you run some checklist to make sure you didn’t forget anything, btu that’s it.

“The future is uncertain … but this uncertainty is at the very heart of human creativity.”
(Ilya Prigogine – Nobel Laureate Physics)

“You can’t manage knowledge. Knowledge is between two ears and only between two ears.” (Peter Drucker – Management Guru)

Therefore ia propose the concept of Adaptive Process that based on a business ontology empowers the business users to create, execute and adapt all processes without long analysis.

Don’t be nagged down by the naysayers. They are the ones that lack creativity and want to enforce their lack of it onto anyone else in the name of quality, cost reduction and enforcing compliance.

Thanks for standing up to be counted. My point of view here:

http://www.adaptive-process.com