MDD

Thursday, 20 August 2015

Fallacies of design and development projects

We have varying experiences, over time, of technology, systems, and products. There are commonly held beliefs and folklore about technologies, how they are developed, what they can and cannot do. When we use systems, make system, we build up pet theories and assumptions about the objects and others involved.

Software is magic
  • The possibilities for software are unlimited (you can make anything you desire if you have the ambition)
  • Your team members are Wizards; although they will be very smart, well educated, experienced, amazing wonderful people.
  • Good design appears 'out of the blue'; it doesn't, it is the product of many cycles of both perspiration and inspiration. This fallacy sometimes pops up as a counter-argument to the principle of customer driven design, often by appealing to a design icon like the iPhone. The counter-counter-argument should highlight that the iPhone 'appeared' after more than 10 years of product revision and market evolution.
You can have all you can eat
  • You can have anything and everything you want; 
  • Designs are infinitely malleable; this is one of the assumptions behind the 'all you can eat' fallacy.
  • Redesigns are cheap; this is one of the assumptions behind the 'all you can eat' fallacy.
  • All requirements are equally important; this is a corollary to the 'all you can eat' fallacy.
People know what they want
  • Requirements are the same as user goals; they aren't!
  • Users know what they want; they don't, but they do know what they like when they see it and use it for a while.
  • Designers know what users want; they don't, not always anyway, and of course designers may be users too, just be careful that the designer isn't always designing what he or she wants instead of what your market needs/wants etche/she is not a Wizard, just an incredibly diligent, sensitive, smart, well educated, experienced, amazing wonderful person.
  • The project manager knows what everyone should be doing, is doing, has done (what, when and where); he/she is not a Wizard, just an incredibly diligent, sensitive, smart, well educated, experienced, amazing wonderful person.
People are stupid
  • Customers/users/developers/managers etc "are stupid"; labelling groups is a symptom of other underlying problems.
  • Someone else is at fault; results in finger pointing, when really the disagreement between expectations and actuality is more likely the result of different starting point assumptions (from Alex Cowan)
  • I must be stupid because I can't use the software; any time you experience an 'I don't get it' moment, rephrase the feeling to 'the designer doesn't get me' (from Alex Cowan).
Software is free
  • Software is free; Nothing is free free, free Apps have costs, even Free/Open Source Software costs.
  • Your time is free; This is the working assumption behind 'death march' projects. Also the working assumption behind designs that impose unnecessary cognitive loads on end users.
One size fits all
  • The needs of the many outweigh the needs of the few.
  • The need of the one is the same as the need of the many.
Lord of the Rings Management
  • Give me the one best solution; the solution could be product, service, system, method, management framework; the fallacy is that everything can be made simple when instead some things are intrinsically difficult or complex.
I know you know
  • But it's in the documentation!; the perfect communication fallacy, 'the documentation' might be nearly anything, from a Market Requirements Document to a bug report.
  • But I told you yesterday!; the perfect communication fallacy. Communication is rarely perfect i.e. what you think you said, what you actually said, what was heard, what was understood.
  • RTFM; Assuming I took the time to read the ** manual. Assuming the information needed is in the manual. Assuming it is well written, comprehendible etc.
Failure is not an option

  • Well actually, it is! In fact it is a very real possibility. That's why we have pivots and product readiness, project reviews
  • Don't get sucked into following this piece of classic leadership claptrap.