Giving Design Advice
In an ideal work environment software designers freely ask for and offer constructive criticism and openly discuss issues. They don’t take criticism as personal affronts, and they and their managers make intelligent, informed decisions.
OK, so how do design discussions play out where you work? In my latest IEEE Software design column I discuss some effective ways to give advice as well as hurdles you may have to overcome before your advice is heeded. Being an effective critic, advisor, and design colleague isn't purely a matter of being on top of your technical game. Cognitive biases affect how people naturally (and often illogically) receive and process information. They can have a big impact on how you your advice is received and interpreted. If you want to get better at communicating suggestions to others, you should become more aware of these biases and look for ways to mitigate or avoid them. Wikipedia has a good overview of cognitive biases in how people assess risk, make decisions, and rationalize them after the fact.
To whet your appetite for this topic I’ll mention one bias that has probably bitten every programmer at least once. A confirmation bias is when a person looks for what confirms a strongly held belief while ignoring or undervaluing contradictory evidence. Have you ever found yourself unable to isolate a software bug because you insisted that your software just couldn’t work that way? Your confirmation bias might have prevented you from noticing facts that would lead you more swiftly to identifying the bug’s root cause. I like the idea presented in Debugging by Thinking by Robert Charles Metzger that taking on the different mindset of a detective, mathematician, safety expert, psychologist (one of my personal favorites), computer scientist or engineer you can get a better slant on tracking down a bug. According to the author, “Each way has an analogy, a set of assumptions that forms a worldview, and a set of techniques associated with it.” In designing as well as debugging, having a variety of worldviews for tackling a problem helps you avoid getting stuck in a rut—and pick the right strategy based on the context. One way to get around a confirmation bias is to shake yourself out of “the normal way of doing business”.
Cognitive biases aren’t good or bad. They just are. And if you work with others it helps if you can identify biases that lead you (or others) to jump to conclusions, hold onto an idea when it should probably be discarded, or ignore risks. That knowledge can help you tune your message and become aware of and avoid bias traps.
OK, so how do design discussions play out where you work? In my latest IEEE Software design column I discuss some effective ways to give advice as well as hurdles you may have to overcome before your advice is heeded. Being an effective critic, advisor, and design colleague isn't purely a matter of being on top of your technical game. Cognitive biases affect how people naturally (and often illogically) receive and process information. They can have a big impact on how you your advice is received and interpreted. If you want to get better at communicating suggestions to others, you should become more aware of these biases and look for ways to mitigate or avoid them. Wikipedia has a good overview of cognitive biases in how people assess risk, make decisions, and rationalize them after the fact.
To whet your appetite for this topic I’ll mention one bias that has probably bitten every programmer at least once. A confirmation bias is when a person looks for what confirms a strongly held belief while ignoring or undervaluing contradictory evidence. Have you ever found yourself unable to isolate a software bug because you insisted that your software just couldn’t work that way? Your confirmation bias might have prevented you from noticing facts that would lead you more swiftly to identifying the bug’s root cause. I like the idea presented in Debugging by Thinking by Robert Charles Metzger that taking on the different mindset of a detective, mathematician, safety expert, psychologist (one of my personal favorites), computer scientist or engineer you can get a better slant on tracking down a bug. According to the author, “Each way has an analogy, a set of assumptions that forms a worldview, and a set of techniques associated with it.” In designing as well as debugging, having a variety of worldviews for tackling a problem helps you avoid getting stuck in a rut—and pick the right strategy based on the context. One way to get around a confirmation bias is to shake yourself out of “the normal way of doing business”.
Cognitive biases aren’t good or bad. They just are. And if you work with others it helps if you can identify biases that lead you (or others) to jump to conclusions, hold onto an idea when it should probably be discarded, or ignore risks. That knowledge can help you tune your message and become aware of and avoid bias traps.
posted by Rebecca Wirfs-Brock at
6:18 PM
4 Comments:
Rebecca:
Reframing advice
so that people are more likely to
follow it isn’t sneaky or manipulative—
it’s common sense. We should employ
every device possible so that our information,
argumentation, and advice are
clearly understood.
Well … agree on the clarity of communication, but the line between manipulation and clarity is interesting and tricky too. I would like to add an aspect that actually complicates the situation a lot. Here I would like to call for honesty in contrast getting my way.
Communicating paradigm shift
In case of OO in many cases the situation in communication is far more complicated. When it is question of paradigm shift then gradual change is not possible but the change must be momentous and dramatic. In this case one have to gather momentum for this change.
When we compare functional decomposition and collaborative agents (or objects) which is equal to OOA these form two different paradigms for analyzing behaviour.
Paradigms are rather big thing. These two paradigms cover the whole concept of application. They explain some whole or give a structure over some complexity. Two paradigms of one subject are always exclusive. Different paradigms talks about same things but in different way. From this all there is a consequence. It is not even technically possible to change paradigm gradually. The change is sudden and in many cases dramatic. Normal human psychology tries to prevent such events from happening, because they are escapes to unknown and will always shake person’s stability.
This means that a person have to gather a lot of momentum to shift a paradigm. An outsider can help gathering that momentum but ultimately the person that have to “cross the border”. Normally this includes also an aspect of no-return.
I was educated in IT way earlier that we knew anything about OO-thinking (which actually developed to the end of 1980’s). So my first paradigm for functional analysis was functional decomposition. The bases of this have different names like: dataflow, process, function, activity flow, use case just to mention a few. By the late 80’s I hade understood that the behaviour of an ER-structure should be closer to the structure than it was. The answer offered at that time where semantic databases, but those where highly complex things and could to the job.
I remember very clearly the day that I changed my paradigm. I don’t recall the exact date but it was at the end of November 1989 in Stockholm, where Peter Coad was giving a 3-day OOA training. Coad’s book on OOA was not ready yet, but he had a blueprint of the book with him.
It took 2 to 4 hour to move me from the old paradigm to the new. I can still remember the feeling. It was a mental earthquake. After the shift everything becomes theoretically clear. The technology was very immature Smalltalk was practically a single user environment, but it was completely obvious that the technology would mature quickly.
After this I (and the majority of OO people) believed that the IT community’s paradigm shift would happen in 5 years time and the process would be completed around 1996. I remember Grady Booch said at some conference (perhaps 1994 OOPSLA) something like: “ there is no OO conferences in 5 years time because at that time OO has become mainstream”. He was right with his first prediction but wrong with the second. We are still waiting for the big breakthrough. The paradigm shift was far more complex and bigger effort than expected.
Actually the opposite has actually happened. It seem that the huge mass concentration in the old paradigm ( all that those countless Cobol application and people developing and maintaining them, old massive software packages with enormous investment and the fear of dropping completely out) that considerably more time is required for that change to happen.
In spite of the fact that OO-languages are actually the only active programming languages, there are several signs of backwards development: UML 2, process analysis, SOA etc. At the times of Smalltalk I was so naïve to think that procedural programming was impossible with OO-languages. How wrong I was then. We have (at least in Finland) a new generation of Java- and other programmers that think in terms of data classes, manager classes “service” class and don’t find class definition without attributes or method odd at all. They haven’t even heard that a class have to bee balanced with state and behaviour and business object basic duty is participation in collaboration. (In UML 2 they even went and changed the name from collaboration to communication!!)
Programming old paradigm main programs with OO languages is actually even more difficult than with 3 G languages.
Jukka-
Thanks for your thoughtful comment. I agree that communicating the benefits of a paradigm shift is quite a bit more than just communicating the benefits of one design approach or technical detail over another.
I do think, however, that communicating designs that require a shift in world view/basic approach will require both educating, inspiring, and making the benefits and risks clearly accessible to the audience. So it is not something that can be done without careful planning of the message. Even so, it may be tough to persuade someone of the benefits and potential rewards, especially if they will result in a benefit "sometime in the future".
Rebecca - Would you recommend Debugging By Thinking as a cover-to-cover read? Seems like a long read (500 pages), and the Amazon reviews seemed to indicate that it was for beginners (though I doubt that a book of that size would be a beginner's book).
Jonathan-
I read many books, but I admit that I have only read a couple hundred pages of Debugging by Thinking. I read those Amazon reviews, too, and they were harsh. I didn't share their opinions. The key thing I got out of this book (and I am likely to buy any book with Thinking in its title) is different ways of attacking and approaching code/debugging challenges.
Post a Comment
Subscribe to Post Comments [Atom]
<< Home