I was recently visited by a friend who is also an IT professional. Some time during the visit, I casually made the recommendation that programmers should take a drafting course. I was a bit surprised to receive a contradictory opinion, but it was well received and has forced me to further justify my position in my own mind.

My case is rather simple; programmers are trained to think in primarily object oriented environments, especially in recent years. Most, if not all, have had some formal training in object oriented modeling using UML or de facto standards in structure design (database or other). This is not coincidence. The reason for this trend is that objects can easily, and often must, be modeled for clarity in design and maintenance. But what isn’t obvious is how those models are generated.

Somewhere in our brain we can start to solve problems and make concrete these relatively abstract relationships with a certain degree of ease.  Not everyone can do it, but most people can draw a diagram of a workflow or an object model. It may be slow but it can be done by most functioning individuals; the key to success is practicing this method.

The trick to being a good modeler is a lot like being a good programmer: process, practice, and perception. You recognize relationships and patterns between past and present problems that allow for streamlining; this is the process. As you do more to practice this process then it can become easier as you have more cases to study and experience to pull from. But the mere act of this problem solving takes a certain flair for the spatial. The perception of the problem and, more importantly, the solution deals entirely with the multidimensional aspects of relationships.

So that brings us to the thesis: training the mind to recognize shapes and objects in their elemental forms will allow for a much easier command when high level design is required. Logically, the drawing tools used by architects and others to define 3-dimensional objects in 2-dimensional space would lend themselves to programmers who deal with multidimensional objects, relationships, and even data. Eventually our goal is the same: get that complex object into an understandable 2-dimensional model. At least until we get the 3-dimensional hologram projectors in the conference room.

To use a personal example, just today I was given a rather daunting task: design a class representation of elements in the TCP/IP stack and a driver that can use those classes to examine network traffic. In addition, this task is part one of three and the code generated should be usable as a larger part of an elementary IDS capable of handling Snort signature rules.

So what did I do? I reached for the notebook and drafting pencil and started sketching out an object model that would best represent the solution with plans for expansion into the second and third phase of the product.  It was elementary, but because I’ve done it before and because of some spatial techniques picked up in Art and Drafting classes, I was able to create a logical model that represented the first picture of the solution.

Of course my solution may not be ready for a text book just yet, but the original draft gives me a lot to work with. Eventually I can redistribute the objects to be a well balanced diagram. I honestly think that this skill is one of the most important ones in the programmer’s tool belt, and one of the best for limiting scope and thinning the FUD fog.

Ps. Part of my research shows a potential correlation to this concept between drawing maps and success in early programming courses (Do map drawing styles of programmers predict success…). It doesn’t have any particularly conclusive results, but it does tickle the brain a bit. Doesn’t it?

Let me know whose side of the argument you’re on. Am I adding unneccessary recommendations to a field already taxed with educational scope creep?