Archive for August, 2010

The Essence of an IS Professional

August 23, 2010

Recently I read the blog of Nicole Sullivan-Haas, who uses the name Stubbornella (http://www.stubbornella.org/). I don’t know why she uses that name and it is not a blog I generally follow (but I may start). In this particular entry, she is discussing women in technology. But, that is not the part to which I want to direct your attention. Rather she provides a nice dichotomy of the difference between good developers and bad developers (the specific blog is at http://www.stubbornella.org/content/2010/07/26/woman-in-technology/).

The code cowboy

* Stays up all night recoding the entire code base, documents nothing, and forbids anyone to touch it because they aren’t good enough to understand his level of code.
* Refuses meetings, chats, or any other form of communication.
* Cares more about being perceived as the brilliant-uber-genius than he does about his team working well together.
* Gets into silly pissing contests which boil down to “hehe, my brain is bigger than yours”.
* Finds complex solutions to problems, thus proving his brilliance.
* Makes a lot of mistakes due to lack of sleep, overcaffination, and ego — but thank god he is around to save the day when the bug is discovered.
* Is fairly certain clients, PMs, designers, and really anyone he has to deal with on a daily basis is at least three standard deviations below his IQ.
* Jumps to say “me, me, me!” when credit or rewards for accomplishments are offered.
* Jumps to say “me, me, me!” when opportunities to attend or speak at conferences arise. The good developer

The good developer

* Digs the fact that he is making products for people. Likes people and enjoys communicating with them and understanding how they think. Can put him or herself in other people’s shoes and reliably imagine how they might react to different parts of the UI.
* An excellent problem solver who takes into account all aspects of a challenge when designing a solution – including human elements like maintainability and usability.
* Shares credit with the entire team or entire internets. Recognizes that no solution evolves in a vacuum.
* Applies consistent effort and recognizes that working in a way that promotes long term productivity will yield better results.
* Respects the members of his team, including those who aren’t engineers.
* Manages projects so they don’t require super human feats of sleeplessness to meet deadlines.
* Has a life outside of work, other interests, friends, and family — they love code, but they love lots of other things too. If you don’t understand how this makes them a better developer, see item #1.
* Amazing capacity for abstraction and creative thinking.

This is a reasonable view of the dichotomy of technology professionals. It particularly appeals to me as I face a new semester with two sections of “systems analysis.” One of the major purposes of the class is to transform people who are in the first column into people in the second column. Believe me, sometimes it is easier to turn lead into gold!

The goal of an Information Systems degree (in contrast with a computer science degree*) is to focus on how the computer is helping the enterprise. The goal is to set the business priorities first and see how computers can reasonably help the enterprise meet those priorities faster, more cheaply and with less stress. In order to be successful, IS professionals must understand the business better than the people in the professions. This is why we require all of those business courses. It requires an understanding of where the business is going and how the system needs to support that growth.

Any professional will want to optimize the product he or she produces – make it bigger and better than anyone else has done before. Sometimes, however, that means that it costs too much or takes too long to produce. Instead, it needs to “satisfice” – to be good enough given the constraints on the system. As a profession, we don’t do that very well. The one kind of constraint that we do not process very well is that of the human component. In particular, what can we expect that human to do and to know and what will that human expect of the system. Said differently, as IS professionals, we need to know how the customer thinks and make sure that the system responds to that well. As a profession, we need to get past the code cowboy behavior and show empathy for the client, and show creativity in our solutions.

So, what’s my point? First, for all of you who are not in IS because you think you must be like the people in column one above, PLEASE change your majors and join us – we need more people of the type in column two. Second, for those of you who want to know how to practice the profession better, focus on the first point in column two – how can you make the system work better for the business, including the people, who work there? Third, of course, if you have any advice on how to transform people from type one to type two (or to transform lead to gold for that matter), please share!