« Linking Agile to HR Theory | Main | Inside the PMI-ACP Exam »

November 15, 2012

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d834527c1469e2017ee52a8bb6970d

Listed below are links to weblogs that reference The Impacts of Iterative, Barely Sufficient Design:

Comments

Grand designs and ornate detail are wonderful ... in art galleries. A systems beauty lies in it's minimalist and fast functionality.

Andrew, thanks for the comment, I would normally agree, but still wonder if repetivive simplification stops anything good, as well as all the bad. Mike

Mike, I think you've encountered the failure mode for many projects. You were simply given the key to your room and left to discover on your own. Consequently, even though you admire the principles behind the design decisions, you reacted to the difference, rather than the result. I had a similar moment of discomfort the first time I encountered a Japanese toilet.

Admittedly, your Danish hosts don't think of you as a user, and don't think of the difference between their hospitality and what you're used to as "change." Consequently, they don't try to manage it. But change management can make the difference between simply changing the artifacts and changing how people work.

Dave, thanks for your comment, but I don’t quite follow your point. I was questioning how the repetitive simplification like we exercise on agile projects may impact the final product. I don’t think my Danish hotel failed, they did a first class job of providing a quality room, it needed no explanation of expectation management, everything was very easy to find and use. Please help me understand the failure mode you mention and how this relates to how we avoid Habitat 67 type systems. Thanks, Mike

This is a great observation and I enjoyed the article. It supports the role of instinct, intuition, and insight in the design process that our industrialist approach sometimes lacks. I have a foot in both worlds as an occasional writer of software and a lifelong visual artist...code is DEFINITELY similar to art and as coders we can learn from the historical working methods of artists, including how to deal with clients that demand more for less (as if this were a simple replicative manufacturing process) while being unable to visualize or describe the result they are looking for. IMNSHO, the factory metaphor is bogus and harmful to the end result. Art and code both require imagination, and force a high degree of innovative thought because each app and each work of art are solitary and unique creations. That's the point! We should never need to write the same app twice, just like a painter or sculptor wouldn't create the same work of art twice. Both have to interact with the human brain which requires a similar mental trick of imagining the unfamiliar perspectives of others who will encounter your work. Agile is great for some things but like Lean and a dozen other methods, it isn't a panacea. To quote Bjork, "there is more to life than this!"

Hi Mike,
I think that our designs are blocky, bland and bare due to the fact that these are more effective (cost-saving) for us to produce instead of the forms that are produced by the nature (or the Gothic architects, for example). In this sense, even simplification can't be understood without understanding the current level of the technology and probably the culture, thus affecting what we finally create. I don't think our stakeholders would not be satisfied, hovewer. Greetings from Budapest!

Hi Kósa,

Yes, I think you have a point and look forward to returning to Budapest soon.

Regards
Mike

The comments to this entry are closed.

AddThis Social Bookmark Button

Your email address:


Powered by FeedBlitz

Tracker

  • Google Analytics
Blog powered by Typepad
Member since 07/2006

September 2014

Sun Mon Tue Wed Thu Fri Sat
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30