When the average person thinks of what an IT consultant does (as often are they are likely to think about it) they generally picture what they see in movies: a somewhat nerdy guy (it’s usually a guy, but Sandra Bullock did break that mold) who is sitting in front of multiple monitors, typing away in an attempt to solve a cliff-hanger problem that requires coding a complex algorithm.
It’s all about the coding.
Those of us who work in the profession see it a bit differently, of course. Coding is a small part of what we do.
There are the meetings, the discussions, the frustrating attempts to set up development environments–everything but actually putting keystrokes to screen to produce a thing of Pythonic beauty.
And there’s one other task that is the predecessor to actual coding, be it a functional UI, or business logic, or a REST interface.
Design.
The design phase is where the real value of a good developer shines. Almost anyone can learn a programming language. But putting that language to work solving problem or meeting a need? That’s design, and it’s a skill that is of immense value.
Design requires abstract thinking, the ability to take a concrete requirement–“put this logo on that web page only if the user logged in from a private account”–and translate it to an abstract representation–“logos will be held in a database table with this schema, indexed by corporate name, with a separate table with that schema with mappings from the user’s account type to a group number representing private/public accounts”.
The latter allows the developer to implement, in the chosen coding language, the bridge between what the code can do and what the end-result is intended to be.
None of this is a new idea to developers–we do it all the time, often without thinking about it.
Sometimes, however, we get stuck in the design phase.
We can’t quite figure out how to do the “mapping” to code within the restrictions of what we have to work with.
There is a concept in psychology called “functional fixedness” that is often the hindrance to this part of the design process.
Functional fixedness is a cognitive bias that limits a person to use an object only in the way it is traditionally used. […] Karl Duncker defined functional fixedness as being a mental block against using an object in a new way that is required to solve a problem.
– Wikipedia
The standard example of functional fixedness is that of the “candle box”.
A participant is given a candle, a box of thumbtacks, and a book of matches, and asked to attached the candle to the wall in a way that will prevent melted wax from dripping on the floor or table.
Most people who are given this task will try to use melted wax or thumbtacks to attach the candle to the wall. This may or may not work, and doesn’t really deal with the request to prevent the melted wax from dripping.
The “best” solution requires thinking outside the box–literally.
Most participants looked at the thumbtack box as just a container for the thumbtacks.
A successful solution required a participant to break through this limited view of the thumbtack box.
The more expansive view? Empty the thumbtacks from the box, and use the thumbtack box as a platform for the candle, held to the wall with a thumbtack.
The ability to overcome functional fixedness was contingent on having a flexible representation of the word box which allows students to see that the box can be used when attaching a candle to a wall.
–Wikipedia
This process of “stepping back” from our preconceived notions of the definition (“a container…”) and uses (“…to hold the thumbtacks” ) to something more expansive (“it can hold something other than the thumbtacks and is rigid enough to hold a candle”) is important, and often very difficult.
There are ways in which functional fixedness can be overcome when in the design phase of a new IT system, for instance. One such approach I like to use is the “generic parts technique”.
In this approach, the designer begins by subdividing the components available for the solution. In the candle example, the designer would first define the thumbtack box component as “a box for holding thumbtacks”. Asking the question “does this definition imply a use?” the answer would be “yes”: this definition implies its use as a “thumbtack box”. Then, ask if this definition can be broken down into a new set of components, or modified to remove the usage implication.
In this case, it might be that “a box for holding thumbtacks” is transformed to “a box”, which can be used for “holding something“.
With that in mind, it’s a simple leap to that something being the candle.
In real life it’s not as simple as this. Individuals tend to get hung up at the functional fixedness stage far too easily. The solution: consider making the process a group process, with the context of the group interaction being “can we find new uses for the components that might help us solve the stated problem?”
This is only one way in which to break through functional fixedness–there are many others. A good source of information on this issue and methods for getting past it can be found here.
Enjoy your new-found freedom in solving design problems!