Software Engineering and IT Professionalism

A few weeks ago I was reading the chapter on Philip Greenspun and ArsDigita in Founders at Work and some of his comments really rang true for me. On a number of occasions I've been in debates with advocates of both agile and traditional software development methods, as well as people from other IT-related disciplines. In my opinion, the argument usually boils down to this question:

How important is it that an IT Profesional take responsibility for ensuring his work delivers value to his customer/client/employer in a cost effective manner?

No one would argue with the idea that it is important to deliver value. No one would argue that it is important to be cost effective. So why would this be such a contentious topic? Well, I think it boils down to an old addage to predates information technology by an awfully long timer...

The customer is always right.

The glaring problem with this is that he is not always right. Not by a longshot. If he were, he would most certainly not be hiring you to apply your brain to create something for him. He would simply apply his omnipotence to quickly creating the perfect software, running on the perfect operating system, on failure-proof hardware. Ok, yes, we all know that. The customer has hired us for our technology expertise. He knows what he needs, and we know how to create it. Right??? Nope. He doesn't. And no one is surprised by that. No self-respecting text on requirements development starts with "The customer/user knows exactly what he needs. All the analyst needs to do is take detailed notes, and the customer/user will precisely, consistently, and completely describe the application that will be his needs." It's all about how users don't know what they want, they have conflicting desires, they tell you what they think you want to hear instead of what they really mean, and so on. I doubt there's any disagreement so far. So what did Mr. Greenspun say?

We had this idea that programmers could be professionals, like doctors or lawyers, and, to that end, we wanted the programmers to be real engineers - to sit down face to face with the customer, find out what was needed, come up with some suggestions or changes based on the programmer's experience with similar services, and then take a lot of responsibility for making it happen.

So what does this mean? Here's my take:

1. A professional will tell a customer when he has reason to believe that the customer needs something different from what he is asking for.
2. A professional will inform his customer when he believes his services will not deliver value in a cost effective manner.
3. A professional will speak in the customer's language, or at least close enough so that the customer can understand.
4. A professional will take the time to understand the customer's need, not just the customer's request.
5. A professional will express "engineering trades" in terms that the customer can understand
6. A professional will make commitments in terms of cost and schedule, and take responsibility for meeting them.

Most "IT Professionals" I know regularly practice at least a couple of these. Very few practice all. Most don't have much trouble trying to make helpful suggestions, and are very conscious of cost and schedule. They try their "best" to communicate effectively, but usually are too concerned with their own specialty than learning the basics of their customers'. Very rarely will they state that their services are not really required, especially in consulting or contracting situations. The end result is exchanges kind of like this:

Customer: We would like our customers to be able to order replacement parts and lookup technical information securely over the internet. Under no circumstances do we want unauthorized people ordering parts or viewing information. Do you have anything for that? IT Guy: We have this piece of off-the-shelf software called WebSphere. It can be used to create an integration hub among enterprise applications. It can also be used to host portals, and can be combined X and Y to implement federated security using two-factor authenitcation and strong encryption.

So let me translate into something the customer would actually understand:

IT Guy: We know of the technology required to do what you want, and have some of the infrastructure already in place. However, we will have to build the website, which we call a "portal," along with the software to connect is to Z, which is our internal system that handles orders. Fully automating these transactions will cost an arm and a leg, and data regarding who is authorized to order parts and access data will have to be extremely well maintained to prevent inapprioriate transactions. The last thing you want is for the factory to build something that the customer won't pay for, because the person who ordered it shouldn't have been able to. Do you think it would be better if we enabled customers to communicate with internal representatives in a highly structured way? Perhaps if that worked well we could add more automation later on. This would be both safer and much less expensive. What do you think? Customer: Oh my God! Of course I want a real person to be involved.

Now the IT Guy just passed up a resume building project in favor of something rather unglamorous. I can think of many other situations where customers have asked for applications dependent on data that didn't exist, direly flawed mathematics, grossly unrealistic assumptions about intended users, and highly exaggerated availability needs stated by customers who didn't want their application to seem unimportant. Faced with this problem, many IT providers hide the techie from the customer. Instead of placing someone who can't communicate in front of the customer, they place someone with no technical skills in front of the customer and have that person communicate with the techies. The problem is this is just miscommunication via proxy. In other words, it is worse. The problem is that professionals are inherently at least partially generalists, while the IT industry has a nasty habit of trying to create line workers. A lawyer can be disbarred for pursuing a frivolous lawsuit (ok, the bar the frivalous is pretty low, but it can still happen). A doctor can be sued for malpractice and lose his license for ordering inappropriate treatments. Entire accounting firms can be destroyed for allowing financial numbers to be misrepresented. These are professionals. They are responsible for their clients, even if it means acting against their client's immediate wishes. But a programmer who hacks together a barely functional piece of software is rewarded for being efficient. An architect who designs a system full of unncessary components is respected for his experience. A system administrator who bypasses proper security to make something work is heralded as a hero. Massive cost and schedule overruns while under delivering functionality are considered perfectly normal. IT people are actively encouraged to be like 15 minute oil change technicians: Suggest a bunch of unneccesary work, while failing to properly do the basics like clean the windshielf or vacuum the floor mats. So more often than not we are not true professionals. Philip Greenspun was right. IT people tend to avoid professionalism, and it is exactly what we need. Innovation in IT can only be achieved by effectively applying technology in novel ways to business problems. All the easy problems have mostly been solved. The only way future innovation can be attained is through a close, effective working relationship with customers. But you can see how that isn't happening. More and more work is being sent offshore. Job posting focus on very specific techincal skills while ignoring the business context. New methodologies place make developers slaves to what customers think they want rather than providers of what customers need. New "innovations" are mostly ways of delivering the same old services - or often diminished services - in a less expensive way. Maybe the tide will turn. I'm sure it will eventually. Progress must progress. Let's hope we can speed it up.

Sphere: Related Content