How to Have Ethics

Ethics is a vast subject, but there are a few key attributes of right ethical behavior that are especially relevant to the professional programmer. The remainder of this chapter discusses five of those attributes.

Honesty

For the professional programmer, honesty is the most important ethical attribute you can possess. Honesty greatly affects our agreements with others, and a large part of the programmer's job (especially during the design phase of a project) focuses on agreements. Honesty is noticed by the customer and others, and so is dishonesty. As a programmer, you interact with many people, including your employer, your coworkers, your customer/ users, and even yourself. Honesty in all these relationships is vital to professional programming.

Some examples of where honesty is important include the following programmer tasks:

• Honesty about your skill level. The professional programmer is very skilled in many tasks, but the world of software changes so fast that no single person can maintain up-to-date information on all aspects of software tools and development. Even Visual Basic brings its own constant learning curve with the release of each new version. When you are asked about the programming skills you possess, be honest. Let your employer know what tasks you are and are not capable of performing. This includes telling yourself honestly if you are selfemployed. Being honest about your skills can save you a lot of headaches later when you have to explain why you were not able to complete correctly one or more portions of an application. Still, being honest does not mean being negative about the skills you do not possess. The professional programmer is constantly learning new tools and new techniques to give the user the best possible software. Although you may not know how to perform some programming method now, you know the rate at which you can acquire new skills. Let those who question you know this great news as well.

• Honesty about a project estimate. Estimates are difficult to produce because they not only involve educated guesses about routine aspects of a project, but also conjecture about components for which no comparable programming work has previously been performed. On top of this, the numbers are often "modified" so that the customer will not experience an extreme degree of sticker shock. This modification puts the programmer in the dangerous situation of having to explain later why the project went over budget. If you are responsible for the estimate presented to the user, do not play the hours modification game with the customer. Be honest about the time you believe it will take to produce a quality application. If your customer is uneasy about the overall cost, see if there are ways in which the estimate can be made more palatable, possibly by trimming off a few unneeded features, or by reducing the unit cost of the billed time.

• Honesty about cost and schedule overruns. Be honest about the possibility and the limitations of cost overruns. The contracts my company makes with customers almost always include a clause that allows a project to exceed the original estimate by up to 15 percent, in case any unexpected or unforeseen problems arise during development of the application. The customer is expected to pay all reasonable costs up to this point. If the cost of development moves beyond this 15 percent due to issues not caused by the actions or neglect of the customer, my company absorbs the loss. If the customer makes requests that move the cost beyond the initial estimate, the customer pays. This honesty up front makes all parties happy. Because no one wants the project to go over budget, honest estimates are delivered and accepted before work begins.

• Honesty about a schedule. Honesty about schedule refers both to the original schedule estimate, and alterations of the schedule caused by modifications to the project after development begins. Honesty in the original schedule coincides with an honest estimate, as discussed in the previous item. All parties agree on a schedule up front, and pledge to maintain that schedule. If an honest schedule is presented before development, the two things that can allow the schedule to slip are unexpected problems arising after development begins, and modifications to the project plan after development begins. The former event is, by nature, impossible to foresee, and once such problems occur, steps must be taken that attempt to minimize or eliminate the effect that the problem has on the project. A more pressing issue is the second one, where someone (often the user) asks for modifications to the original estimate. If these modifications are accepted into the project, you must be honest about the effect they will have on the schedule (and the cost). Be direct about any extensions to the delivery time of the project, and clearly document all modification requests. Maintain relevant e-mail requests, and for large projects, only allow modifications with appropriate management signatures. This honest approach keeps everyone on schedule, and expectations unambiguous.

• Honesty about provided features. Being honest about the features that will appear in an application starts during the planning phase. In the previous chapter on planning, I stressed the importance of understanding the needs of the user. If you do not understand some aspect about the user's task, be honest about it, and obtain a clear understanding before planning ends. Then you will be able to provide those features that are most needed by the user. Giving the user the features he or she needs is important. Giving the user features you know he or she will never use just so you can increase the cost or lengthen the schedule is unethical. A professional programmer does not engage in such activity, or have such an attitude. However, you may know of extra features that will be beneficial to the user over time, and explaining these benefits to the user is a good idea.

• Honesty about problems when they arise. If problems do occur, be honest about them as soon as necessary. "As soon as possible" is not the right expression because you should take some time to determine the nature and extent of the problem before concerning everyone about it. Still, keeping silent for too long about an issue during development can have disastrous consequences later on.

• Honesty about expectations. Be clear about what you expect from the user. That is, confirm with the users that their involvement is not optional, but required, to deliver a quality application. This will be especially important when problems occur in the application. Many users do not understand (or care) how to provide adequate diagnostic information. Does this sound familiar?

Tech: Thank you for calling Very Soft Ware technical support. How can I help you?

User: Your program crashes when I use it.

Tech: Which of our products are you using?

User: The one that crashes!

Tech: Are you using our word processor or our spreadsheet?

User: Well, your processor, of course. Does your spreadsheet crash too?

Tech: What were you doing when the program crashed?

User: I was writing a letter.

Tech: Could you be a little more specific?

User: I was writing a letter to my mother.

Most users are not intentionally belligerent or cruel about problems. Most users just want to get their work done, and they are upset that your application stopped them from doing so. However, it is also true of most users that they do not know how to report sufficient details to diagnose the problem. Make sure you express your expectations about error reporting and other issues up front to the users. Help them to help you by supplying the materials (either in the program or externally) they need to meet your expectations. This may include supplying a standard error report form for the user to fill out in the unlikely event of a program failure.

Trust

As a programmer, you have a great advantage over the user: a clear understanding about how a software program works. The customer (or user) often knows nothing about programming, and sometimes knows little about how to use a computer. Although training can overcome some of the gaps in the users' understanding, they still must trust in you enough to write the program that best meets their needs. Never take advantage of a user's lack of computer knowledge to provide an inadequate software solution.

Building an atmosphere of trust is essential during all aspects of a project. If the users know that they can trust you, they will be more relaxed about conveying to you the various elements of their work, and sometimes they will entrust you with information about problems in the design of their current workflow. You can use this information to create a better application for the users, even further enhancing their trust in you.

The customer is entrusting you with more than just a portion of their budget. For many Visual Basic projects, you are entrusted with the heart of the customer's business, the ability to perform a service or produce a product efficiently. Your application can mean efficiency or inefficiency, and it does make a difference to the user. Often the customer is also putting their data into your care. Misusing, damaging, or divulging that data is clearly unethical. Suggesting better ways to manage that data, however, is ethical.

Having the customer trust you is also important for your employer, especially if you are a self-employed Visual Basic programmer. Trust is a key to repeat business, and since most software firms are not charitable organizations, repeat business is desirable.

Quality

Quality is one of the important ethical traits of the professional Visual Basic programmer. Quality work announces to the world the skills of the programmer, and like a résumé, it presents in a coherent form the qualifications you possess to implement software solutions. Always be relentless to provide a quality application.

Quality is one of the three legs of the supposedly mythical "schedule-cost-quality" model. This model is deemed mythical because of the impossibility of supplying all three items to the satisfaction of a customer. The theory states that you can have any of the following:

• Short schedule, low cost, poor quality

• Short schedule, high cost, good quality

• Long schedule, low cost, good quality

However, you cannot have short schedule, low cost, and good quality. Actually, I hate this theory, and I have always fought against it, but it does seem to be true. I once received a joke award from a customer stating that I had displayed the "feasibility of the schedule-cost-quality model" because of my attempts to reduce modifications to the scope of the project once development began. Now I can look back on that moment and laugh, but at the time I received this award, I was somewhat upset and embarrassed since the customer never once approached me professionally about the serious business needs that warranted modifications to the application.

I tell you this story not to sing you a ballad of my past miseries, but to present one of the challenges of quality. If you have a customer who refuses to allow a reasonable amount of time, or a reasonable investment of funds, into a project, quality will likely suffer. It is up to you, as a professional programmer, to make it clear to the customer, and all interested parties, the importance of a quality application.

Quality is a difficult attribute to define, since what may be an important aspect of an application for one person may be overlooked by another. Still, there are some constants that run throughout all quality applications. These constants are elaborated on in the other chapters of this book, but some general aspects of a quality application to consider are:

• Meets the needs of the user

• Easy to use and understand

• Consistent interface and usage throughout the application

• Sufficient documentation and support

• High performance level

• Bug free

• Maintainable and modifiable

Ownership

Ownership for the programmer is a difficult issue, since you will rarely be the official legal owner of either the completed application or the data it manages. Even if you work alone to produce a mass-market application, your users will consider themselves to be the owners, not you. Since they paid for your product, they will be correct in that belief. Still, the programmer is not a disinterested party when the ownership of an application in development is under consideration.

During the development process, the professional programmer should consider himself or herself to be a co-owner of the application along with others who are involved in the development process. Co-ownership carries with it two important facets. The first is that you do not possess sole rights to the end product (although in some situations you may legally be the sole owner). By sharing ownership with others, you take their needs and contributions into account while development is under way.

The other component of co-ownership is that, as an owner, you bear a certain amount of responsibility for the application. The more professional you are, the more responsibility you should be willing to bear for the portions of the application under your control.

Taking ownership for a project (or the portion assigned to you) is not a "keep your hands off, it's mine" power grab. Rather, ownership evokes the desire to bring out the best in the application, just like the owner of a classic car desires to restore the vehicle to mint condition.

Once I was discussing a project I was in charge of with the customer. Several times during the conversation I described the application as "my program" (to distinguish it from other development efforts at their office). Soon the customer became agitated. "I am paying you to write that program. I own it. You will stop referring to it as "your program."" Perhaps I should have been more careful in my terminology, but I believe that any customer should be happy to hear their competent, programmers call a project "mine." Such a statement is not a claim of legal ownership, but of responsibility. The customer was accurate in identifying himself as the legal owner of the application. Yet the responsibility-based ownership of the application belonged both to the customer and to the programmer.

Humility

Humility, the last of the ethical attributes discussed in this chapter, is the most subtle of the attributes, but it can have one of the most powerful effects. Humility does not always come easy to good programmers. Hey, we are good, and others know it. That is why people ask us to write programs for them, right?

We have all met people who thought they were better than everyone else, who in truth were only mediocre at what they did at work. I have met people who were as good as their self-proclamations, but their boasting made them quite difficult to work around. The professional Visual Basic programmer is very good at programming, and the user knows it. However, that knowledge does not come about from boasting, but from the professionalism of the work.

Humility does not mean you hide the truth about your competence from others. If you did, you would be shirking your responsibility for honesty stressed earlier in this chapter. Yet the knowledge of your own skills is not something to be lorded over others. Proclaiming your qualifications with the blast of trumpets can be like erecting a brick wall over which your customers and coworkers refuse to climb.

Consider the ideas and suggestions of others, even when those suggestions run contrary to your own ideas about how an application should be designed. Once after delivering a prototype of an application to a customer, several points of difference arose. Although most of them were clarifications of the original plan and its implementation, one issue was aesthetic in nature. I had designed a form to collect basic customer information, including the full first, middle, and last name. Although I do not remember the exact field lengths any longer, I do recall that much more space was allocated for the first and last names than for the middle name. The form I presented had fields arranged similar to what is shown in Figure 8-1.

After the customer reviewed the application, they insisted that I visibly shorten the middle name field. Although I tried to explain about the importance of a consistent look, and even directed them to such instructions as found in the Microsoft Windows 95 User Interface Guidelines book, I was overruled and required to change the form (Figure 8-2).

This is where humility is necessary. Misaligned fields tend to irritate me, and I was not happy about shortening the middle name field. But the customer had a legitimate reason for modifying my design. As the one paying the money for the project, the final word rested with the customer. I was humbled, not because my design was wrong, but because the customer felt strongly enough to change one aspect of the program. This was not a loss for me, but a victory for the user.

Above all, be easy to work with. Like it or not, any programmer can be replaced. Still, it is difficult to replace a truly professional Visual Basic programmer.