• View
• Edit
• History
• Print

GulfBetweenUsersAndDevelopers

Philip Guo - The Two Cultures of Computing

Re:Common developer problem (Score:4, Interesting)
by causality (777677) on Saturday March 14, @06:20PM (#27195943)

The problem is that we NEED someone to care about the underlying architecture. If nobody does, the system fails.

Yeah, sure - most users see computers as magic black boxes. But they wouldn't exist if everyone just sat around looking at a box and wishing for rainbows and unicorns (although you might get some nice books / movies). Someone's got to open the box and figure out what's going to go in to it to make it do the things people will take for granted tomorrow.

It's for just that reason that I question this mostly unstated assumption that anywhere there is a gap between developers and users, that it is somehow entirely and automatically the job of the developers to bridge that gap. When you are talking about Open Source software that is both free as in speech and free as in beer, there is certainly no moral expectation that this should be the case.

The average users in this scenario are non-contributing beneficiaries. Non-contributing beneficiaries who are demanding instead of helpful are beggars who are trying to be choosers. Here, I'm not talking so much about what is said and done so much as the way it is said and done and the intent behind it. It's one thing to politely ask for a feature or a change because you think it would be great. It's quite another to make judgments about someone's character or their ability to figure something out because their free contribution was not to your liking.

By and large, these users are unwilling to acquire the skills necessary to implement the changes that they demand from the developers and yet some of them are willing to pontificate about how a developer should think. When the GP said "Sadly, many developers never figure this part out", that is a manipulative way of saying "they seem to disagree with me about what should be important." I say that because some things genuinely are "sad" while others are merely differences of opinion and it is intellectually dishonest to conflate the two. The only reason for doing it is to give an undue appearance of superiority to your own viewpoint but if your viewpoint were truly superior, no such tactics would be needed.

Furthermore, this is a difference of opinion not between two equal viewpoints but between a contributor and a non-contributor. Beware the tendency to automatically consider all viewpoints to be equal. It has a certain allure because it can sound noble but there are many times when it just isn't the case.

When you unnecessarily phrase something in a manipulative fashion, subtle though that may be, it has some interesting effects. Most people are not aware enough to understand why or to see this process as it occurs, but what happens is that they instinctively sense that there is a "wrong feeling" to it. Unfortunately many people, even those who can see this happening, lack the strength to just calmly point it out and show by their example that there is another way. They don't know how to experience it without being affected by it because they are externally motivated and it is external ("externally motivated" = "responds to pressure"). So when they sense this "wrong" feeling there is a tendency to either appease it or to fight it, depending on the character of the person. Both are wrong because both are harmful.

Appeasing it is a mistake because it validates the tactic and sends the message that it's acceptable and will obtain the desired results. It also robs the appeaser of much of the joy that could have been found in the creative process by replacing noble service with demeaning servitude, a process that tends to breed resentment. Fighting it results in senseless pissing contests and personal arguments which reinforce the "us against them" mentality, in this case "the interests of developers vs. the interests of users". It also makes sure that your position is no better than that of the other person and so it destroys your ability to lead by example even if you were initially correct. There are wrong ways of being right.

The danger is in extremes. Change too much and you have an unusable system that's never functional as it's always in preparation. Change too little and you have no improvement. End users should realize that they, ultimately, benefit from change - for every thing that they couldn't do without today, there's someone who remembers when it didn't exist (mortality and history permitting). But developers must realize that the changes they're implementing are future targets and they need to consider the method that gets people to those targets while the changes are being worked out.

Well said. I would add that I'd like to see developers and users realize these things together instead of feeling like they have overlapping yet conflicting interests.