Critical Thinking in Software Design

There is a great article published at Inc which enumerates four secrets of great critical thinkers. I find this is totally relevant to designing software or software architecture. So I’m adding my take on these four secrets:

1. Slow Down
   One of my main gripes about meetings is making a decision on the spot. At least for me, my best thinking occurs somewhere else after the fact. I need time to consider the implications and possibly see alternatives before I can be certain it’s the correct decision. So to make the most effective decisions, postpone immediate decisions as often as possible. Make the time to explore the alternatives.
2. Break from the Pack
   This is the basis of one of the main arguments by Ted Neward in his keynote at Codemash 2012 that I already covered. The “best practices” are found in books, on the web, in corporate documents. Generally, these can get the job done. But I doubt it’s always the best or right solution to a problem. It’s certainly the safest. If that’s the goal, then go that way. But in business we are always looking for the advantage, and I doubt the best practice gives you the advantage. More likely, it’s a starting point which you should use to find the best solution. Slow down and think about how the best practice solves the problem and if that is really the solution you need.
3. Encourage Disagreement
   I have long used this as a metric in my interview process. I want team members who will express their opinions. Usually the best answer to a problem is not the result of the idea of a single person, but an amalgamation of ideas or compromise between multiple ideas. If no one can disagree with the boss/tech lead/manager then you might as well adopt only the best practices and call it done.
4. Engage with Maverics
   I think this one is a little harder in an enterprise environment, since often a big corporation is not the home for maverics. I think what you need to do here is actively engage with people whose viewpoints are not aligned with yours. People who think differently about a problem may provide you with some insight you may have missed or not considered properly. I have always thought of code reviews as a source for this. I approach them as a way to see someone else’s problem solving at work. I’m not interested in telling them how they did it wrong, but seeing what they did well and adapt that to my problem solving toolkit.