REVERT TO CONSOLE

If you are a software developer and haven’t realized by now that a BS in Computer Science should be at least 50% BA, then you must be living the good life and I envy you. Though users love to believe that software development is a perfect science that is as predictable as manufacturing wing nuts, we know that to be far from the truth. It is in fact, the user, that makes any attempt to apply scientific methodology to software development futile.

The user is not “the enemy”, nor is the user “stupid”. Without users, there is no software. Users are simply human beings. Their minds are not bound by physical limits, such as volts, amps, or aerodynamic drag. A human’s mind is capable of dreaming up anything, whether it is possible or not in the physical world. In software we operate within a virtual world not bound by earthly physics. This fact combined with the vast imagination of the human mind is what makes software development so challenging. Without boundaries and limits, you can easily find yourself in a no holds barred situation.

Therefore, it is imperative that developers impose and enforce boundaries upon the user. There are many examples of this: change control boards, requirements sign off, iterative development, etc. While these conventional measures serve their purpose, it is sometimes necessary to take extra steps that may be ethically questionable.

You need to know the following:
1. The user does not really know what he/she wants
2. The user needs to be told what he/she can and cannot have
3. You are in control of the software, not the user
4. You are the technical expert, not the user
5. The user doesn’t care about how the software works, so long as it works

We should not feel guilty about the nature of software development, nor the ways in which we deal with the above facts. To deal with those facts mentioned above, consider the following:
1. Lead the user away from ideas that will result in requiring complex features, while persuading them to accept ideas that will require simpler ones.
2. Be firm with what features can and cannot be built. Remember, the user is not the technical expert. You can bend the truth a bit with your imagination and technical knowledge.
3. Do not ever give control of development to the user. Always require him or her to follow proper procedures for change requests, it doesn’t matter how “urgent” it is. Unless there is a defect causing people to die or the company to lose massive amounts of money, it is not urgent enough to skip the procedures and processes that have been put in place.
4. Do not be fooled by a user who claims to be an expert as a software developer. Unless they are working on the same software that you are, their “knowledge” is useless. Users with strong educational backgrounds love to make these claims. (i.e., M.D.’s, P.h.D.’s) Do not be intimidated. Have confidence in yourself and your abilities. If they are persistent about injecting their own technical “expertise” into your project, do whatever it takes to take them out of the picture. Get his/her manager involved if you have to. If you give in to this type of user, you could very well be jeopardizing the health of your entire project.
5.The user doesn’t care about how the software works so don’t tell him/her. Not only is it a waste of time, but it also keeps them in the dark. That allows you to bend and manipulate the technical truth to your liking if need be.

The last issue I would like to mention is the issue of deadlines. You should set these, not the user. If the user requires a deadline that is not reasonable, then tell him/her you will have to drop features in order to meet that deadline. You cannot give up control. Lie, cheat, and steal if you have to. I can’t really see where you’d have to do the latter, but I am serious here. Do whatever it takes to maintain control.

Again, the user is not the enemy (except maybe those “experts” described in number 4 above). The user just needs stringent boundaries and limits. These boundaries need to be firmly enforced, even if it means engaging in questionable tactics at times. Sometimes you may have to approach your job like you are a slightly less than honest politician. The end result will always be worth it. If you can keep the user in line, you will find your job to be much more rewarding.