Complexifiers and Simplifiers
Read an interesting discussion at Berkun Blog: There are two kinds of people: complexifiers and simplifers.
There are two kinds of people: people that make things complex and people that simplify.
Complexifiers are averse to reduction. Their instincts are to turn simple assignments into quagmires, and to reject simple ideas until they’re buried (or asphyxiated) in layers of abstraction. These are the people who write 25 page specifications when a picture will do and send long e-mails to the entire team when one phone call would suffice. When they see x=y, they want to play with it and show their talents, taking pleasure in creating the unneccesary (23x*z = 23y*z). They take pride in consuming more bandwith, time, and paitence than needed, and expect rewards for it.
Simplifiers thrive on concision. They look for the 6x=6y in the world, and happily turn it into x=y. They never let their ego get in the way of the short path. When you give them seemingly complicated tasks they simplify, consolidate and re-interpret on instinct, naturally seeking the simplest way to achieve what needs to be done. They find ways to communicate complex ideas in simple terms without losing the idea’s essense or power.
And my first gut feeling was, hey I see them every day, and almost every where. Particularly software consultants, who love to see themselves as Experts often tend to make things more complex, with their flashy and non-sense jargon, which they themselves could not comprehend. Because, some people tend to think you are not doing any thing great if it looks simple. Neither true nor false completely. We see all these people every where. Here is what I think on Complexifiers and Simplifiers, (as commented on the original blog post)
Having more details should not be considered as complex. On a similar note, lack of details does not make it simple.
Whatever we do not understand with clarity, we often consider it as complex. Whatever we can easily undersand, we consider it as simple. So then (to a greater extent), complexity or simplicity is a subjective assertion, based on one’s understanding.
For a given problem, if somebody give a new solution that no body is aware of, people often tend to think the solution as complex, purely because they could not comprehend the solution and consequences. But if we give a solution that is understood well by others, they consider it as simple.
In my experience though, good problem solvers explain a solution with an analogy from a well known solution for understanding, and then delve into details that are quite new in the solution. End of the day, everybody understands the solution, so do not see any complexity.
Some people, who mostly out of lack of confidence, and insecurity do not want to have their solution understood by others. So they add too many irrelevant details to their solution and tend to explain the solution in a foreign way, with full of jargon and (commonly)unknown terms. The solution may be quite simple, now look unnecessarily complex.
While reading the comments, I found a great link to The Programmers' Stone posted by michael j talarczyk, that discusses about how software programmers think. I find it very interesting. Its a great 7 chapter long article that delves in to lot of depth in Software development.
The purpose of this site is to recapture, explore and celebrate the Art of Computer Programming. By so doing we hope to help the reader either become a better programmer, understand what less experienced programmers are struggling with, or communicate more effectively with other experienced programmers.
Tags: software, programmer, the art of programming, inspions
Comments