The Essence of an IS Professional

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!

Architecture and Systems

Friday’s TechNews highlighted some work being done at the University of Leicester by saying:

The University of Leicester’s Farah Lakhani is studying how techniques from architecture could be used in the development of software for embedded processors, which have grown in complexity. Lakhani says the designs of buildings and control systems share commonalities. “Architects must couple knowledge of engineering–for example what type of steel girder is required to support a floor–with human-centered design, i.e. what makes a building a good place to live or work,” she says. Lakhani says that similar concerns should be a focus of developers of embedded systems, and her current research focuses on “how techniques called ‘design patterns’ from the field of architecture can be used by developers of reliable embedded systems.”

It is quite obvious that we can learn from architects — and not just for embedded systems. In fact, the object oriented movement has highlighted the work of Alexander. His views of “a property without a name” drive my doctoral students crazy until they “get it.” While the field has gone on to document many patterns for design, they have been less likely to document the patterns for analysis. In fact, my reading of Alexander is that he believes patterns for analysis are more important than those for design. Specifically, knowing what kinds of issues need documentation for specific kinds of problems, what kinds of stakeholders probably exist in what kinds of situations, and where problems tend to appear for certain kinds of problems would be most helpful for novices in analysis. Accounting systems differ from personnel systems — there should be help for the novices to know how to approach them. Further, many of the failures of systems can be tracked back to bad analysis (not understanding the problem, not communicating, etc.) than to design. Thus, patterns in analysis would be more critical. Of course, the reason they don’t exist is that it is much harder to define analysis patterns than design patterns. I wonder how we would start?