Programmer Musings

Geek Gauntlets revisited

I recently finished reading Eric Sink on the Business of Software. I had read many of the essays before and, in general, I like what Sink has to say. I'll freely admit that he knows a lot more about the business of software than I probably ever will, and I'll normally take his opinion over my own on any subject in that area...However, I found that one of his essays (Geek Gauntlets) made some arguments that I didn't agree with. As I thought about it, I realized that the essay makes the same mistake he was accusing programmers of.

I would suggest you read his essay to be certain you understand his point rather than just taking my interpretation. Sink makes some good points and explains some realities of business very well in the process. The point where I believe he goes wrong are two examples of programmer bias. Let's start with the first:

Commercial Version Control

According to Sink, a programmer at Gnomedex once asked him why anyone would buy his commercial version control system when CVS is available for free. In the essay, Sink dismisses this person's question as a case of bias and states that we need to learn to see things through the eyes of the customer. He assumes that technical people just don't understand why a customer would ignore a good technical answer that is freely available. I find this reaction frustrating because I can see asking the same question. Not because I have anything against the SourceGear Vault software, but because I want to understand what the customer wants.

In all honesty, I don't completely understand the customer's decision to go with the commercial tool. But, I do understand some of it. The problem that the customer is trying to solve is only partially a technical problem (version control), it is also partially a business problem. Some of these requirements are important to know:

• software must interface well with their current development environment
• possibly large amount of revision history in a format compatible with Vault, but incompatible with CVS
• knowledge and abilities of the customer's staff
• corporate standards
• features may be provided by Vault, and missing from CVS
• customer support, including hand-holding
• a corporate face on the product

Some of these reasons are technical, the CVS development team might want to consider making changes to support these features if the need is great enough. But most of them are non-technical issues that cannot be solved by any technical means. In many cases, the business reasons trump the technical reasons. Just stating that companies obviously make money in this field, therefore the question is ridiculous, does not help this programmer or a wider audience understand these issues. I would be interested in knowing which of these issues (and others) really seem to influence customer decision in his experience.

In many ways, those of us who choose technology for our livelihood find it hard to understand these kinds of issues. But, those in business are also often blind to technical issues. I wasn't there, so I don't know if the programmer's intent was obvious in his tone and Sink was justified in this viewpoint. But, I did find his (reported) reaction somewhat less than helpful.

Passport

In his next example, he describes a case where the company was considering the possibility of adding support for Microsoft's Passport into their software. One of their developers made the comment that "Passport makes my skin crawl". Sink argues that the developer's reaction was biased and unhelpful. He goes on to point out that if the customers want it, we need to lay aside our bias and implement the customer's requirements.

I remember looking at Passport some time ago, and what I saw made me agree with that developer. (I have not looked at it recently, so I don't know if those opinions are still valid.) I have also been in situations where the customer wanted something that I felt (or knew) was a bad idea. Following Sink's advice seems to imply that I should have just shut up and done what the customer wanted.

In one case that I can think of, I was working with a company that provided financial information from a number of sources on websites that we built for large customers. At one point, one of the customers demanded that I remove the copyright notice that identified one graph as coming from a third party. The customer really wanted this, but I was pretty sure that we couldn't do that. (I didn't know all of the details of the contract allowing us to display the data.) I refused and passed the information on to our project people.

After quite a bit of discussion and checking, it was determined that if I had done what the customer wanted, I would have placed my company, not the customer, in legal problems. Although this was not a technical issue, I applied my knowledge to overrule a customer's desires.

Although this does not seem to relate to the example in the essay, consider this. Let's say for the sake of argument that the developer had been correct and that Passport was a really bad idea. Let's also consider the possibility that he was overruled and that the Passport compatibility was added to the software anyway. Now imagine what would happen if a flaw in the Passport login system had compromised the customer's server allowing their repository to be accessed or damaged. What if the compromise had allowed unauthorized access to the corporate network. Who will be blamed? Do you think it will be the customers who asked for this functionality? Do you think it would be Microsoft? Or, do you think that Sink's company would take the hit?

Part of what the developer was doing was identifying a risk. He may not have done that in an business-like manner, but it was a risk to be identified. As such, it was entirely appropriate to be discussed in a meeting to determine if the technology should be considered. This risk should have been researched and determination made on whether it was a problem or not.

Conclusion

It might not seem like it, but I do agree with much of what Sink says in his essay. However, I think it might be worth considering that knee-jerk business reactions are no better than knee-jerk technical reactions. Sometimes we have to do things that we don't like to make the customer happy. Other times, we need to be able to use our technical knowledge to prevent customer requests from leading to later disasters.

In several of his other essays, Sink states that the technical knowledge is critical to running a technical company. Many of his decisions are based on both technical and business knowledge. The examples in this essay suggest that business understanding and customer desires must always overrule technical issues. I am simply arguing that the real answer is more complex than that. Any decision is a set of tradeoffs. Although we (as technical types) tend to favor the technical issues, we need to be aware that business issues are sometimes more important. Just as importantly, real technical issues sometimes cannot be ignored just because the customer wants it.