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. |
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. |
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!