> Who gets to decide?<p>In my experience with software development at bigco, it's the lead architect-type person, who has the direct ear of upper management and has already made a decision well in advance of the developers/designers even hearing about the project. This decision will not be communicated in advance, rather people must generate several good ideas that will then be pared down to something close to what the architect originally had in mind, though they will all be moderately unsatisfactory due to the obvious limitations in this process. The result is a product that no one is completely happy with but at the same time no one can completely fault because of the extensive research and consensus that went into its development. This lack of enthusiasm will trickle down through the rest of the project until everyone is just looking for a way to get onto some other, newer project that is still untainted yet will inevitably undertake the same cycle in due course.<p>If a truly excellent idea should arise from the independent investigation, it will be shelved for a 2.0 product release due to the "perceived risk" or "out of scope requirements".<p>From the outside, however, this process looks exactly like the diagram in the article.<p>Pardon my cynicism, I suppose this is why I got fed up with commercial software development...I hear it's not like this everywhere;)
I think one of the most revealing moments in my design education was when a teacher asked us to design a packaging that looked <i>cheap</i>. We all felt relief because we thought it meant we didn't have to be as careful with the quality of our design, and in general most proposals were shoddy and poorly built.<p>Of course, the teacher chided us for being careless, "looking cheap" doesn't mean low quality, it means subtle signals like inexpensive materials, no flourishes, no 'status symbol' indicators.<p>When looking at certain design pieces we often have a visceral reaction, you either like it or you don't. You must step back and think about the purpose, if the design accomplishes its purpose then it's good design. The aesthetics might be off, but that's easy to fix.
In Design school, we learned how to criticize without being jerks. We also learned to trust other people, and take criticism without being offended.<p>After 4 years in an environment like that, I'm amazed at the design process in the startup world. People cling to their pet projects -- and they either don't criticize for fear of hurting someone's feelings, or they take criticism very personally.<p>I take this skill set for granted, but there aren't that many places to learn how to give and take criticism, and many companies have not figured out how to embed it in their culture.
The most important piece of advice is the last line of the article.<p>In my experience, ignoring the above combined with a refinement only approach generates some amazingly horrible 'solutions'.<p>An example of one such 'solution' I was forced to implement by a manager and 'senior developer'. To make matters worse I was expected to be the one to supervise/troubleshoot the use of this 'solution' every week. Here goes:<p>Output data on a unix server, ftp it to a Windows server, ftp to a Windows PC (yes, it was FTP'ed twice on the same LAN), manually change in Access and export, ftp back onto the server, process again, FTPx2 back to the Windows PC, email to an off-site processor, wait 2-5 hours for a response, ftp back to the Server, process, ftp back to Windows, put it into Access again and export, and then ftp it to the clients mainframe (and manually remember to add some archaic FTP settings). On average it took 1.5 hours of dedicated work time to complete, not including the wait time or reattempts. It was extremely error prone due to the number of manual steps. Changing the settings in ftp also caused problems with other clients when people forgot to take off the archaic mainframe ftp settings.<p>For my own sanity I assumed responsibility of the task being done each week and replaced it with a script that did <i>everything</i> in half a minute including sending it off for offsite processing - the results of which I never used. I was eventually found out when the client requested the data early and I provided it to them several hours before the offsite processing was done. I got in trouble because of the thank-you email.
If we're ever in a design meeting together, please, please don't act like this.<p>I already know the benefits of my design, that's why I presented it. I don't need you to point them out again. I need you to criticize my design and think hard about edge cases I've missed. Don't waste time trying to think of something nice to say, spend your time trying to tear my design apart.<p>I might feel bad to have the flaws pointed out, but I'll feel a hell of a lot worse if we go forward with my design only to find a devastating roadblock months down the road.
> <i>by making a rule of praising alternate solutions and criticising your own, the discussions move clear of the realm of personal preference and bias. It's simply a discussion of what is right, and when.</i><p>How strict should this rule be? Where does it end, and where does legitimate criticism begin?<p>It is an illusion that people can simply talk about "what is right and when" without getting caught up in biases. Biases just get subtler and therefore more difficult to catch. Everyone who strongly favors one or another solution does so because they think it's the <i>right</i> solution, not merely because it's their favorite solution. You can't escape that by simply declaring that you're going to talk about what the right solution is. Meanwhile, people are often incapable of seeing all the shortcomings of their favorite idea, because it's their favorite idea. When that happens, you need other people to criticize it for you.<p>A rule that tells you to criticize your own idea and flaunt the benefits of other ideas could lead to suboptimal solutions when people try too hard to please one another and not all of the shortcomings are identified. What if you know that the other guy's solution will break down in an edge case that he seems to be totally oblivious of? The proposed rules of the discussion subtly discourages, if not prohibits, you from mentioning it until a later time when it might be too late. Of course you shouldn't be a hothead all the time. But if the only alternative is to express your discontent in a passive-aggressive, underhanded manner, how is that better than, for example, using Crocker's Rules [1] ?<p>But I guess it ultimately depends on the personalities of the people involved. If you've got a bunch of hotheads, maybe they really need to cool down and start thinking positively. But there are always some people who are really good at spotting problems but who are afraid to hurt anyone's feelings. You really don't want to discourage them any further.<p>[1] <a href="http://www.sl4.org/crocker.html" rel="nofollow">http://www.sl4.org/crocker.html</a>
This sounds a bit like the complement sandwich: start with a positive (where it works great), then criticize (where it falls short) and wrap up with another positive. Oddly enough, even though its a bit clichéd, it is a remarkably effective little tool.
I often find it hard to settle design arguments when:<p><pre><code> - we lack data
- business is at risk
- there's some organization quarrel going on
</code></pre>
Unfortunately that's too often the case. I am still unsure how criticizing your own work help solve those problems.
This is great because it forces participants to carefully consider the _details_ of each others' designs.<p>As a designer moves along he or she will invariably encounter lots of little constraints that were previously unknown. A good design is a response to all of these details. As a reviewer its all too easy to dismiss a design: "you should have just done X". But the designer will respond "it was considered but I found extra requirements Y and Z that preclude X."<p>Communicating these details is difficult. You may not always remember all of the constraints you've discovered. A process like the one posted should help to get everyone thinking about the details discovered by each individual.
Hmm.. this reminds me of a design presentation I saw a while back that talked about using the "6 Thinking Hats" approach. Basically, after creating a number of designs, a facilitator walks team members through six different ways of thinking about a design. I guess it covers the same ideas as "walking both sides of the street", but it was suggested that 6 hats is easier to apply when dealing with non design personnel.<p>Quick googling got me this page:
<a href="http://www.idspace-project.org/index.php?option=com_content&view=article&id=66&Itemid=53" rel="nofollow">http://www.idspace-project.org/index.php?option=com_content&...</a>
<i>One surprising knock-on effect of this approach is a reduction in pointless design arguments. The ones that are rarely constructive, where people get offended and cling on to their own precious concepts.</i><p>I think the strategy described is elegant in its directness. It's just a simple inversion of people's natural tendencies -- the very ones that get people into pointless arguments.
> "The person who demonstrates most knowledge about the shortcomings of their own solution and the benefits of all the alternatives is the best best equipped to make the call."<p>I like this approach of having the person who points out all of the good in others' designs and the flaws in their own designs is best qualified and/or unbiased to make the call on the "best design."<p>How do you identify this person though? Isn't "the person who demonstrates most knowledge about the shortcomings of their own solution and the benefits of all the alternatives is the best" a subjective determination? What if a handful of people are all demonstrating this ability? Do you have all of them "make the call" by committee? That seems to defeat the purpose of this exercise...
From personal experience those who give the most useless kind of criticism tend to be very aggressive when receiving even the mildest form of constructive criticism, or even suggestions.