This post originated from an RSS feed registered with .NET Buzz
by douglas reilly.
Original Post: A Developer's Duty to do the Right Thing
Feed Title: Doug Reilly's Weblog
Feed URL: http://www.asp.net/err404.htm?aspxerrorpath=/dreilly/rss.aspx
Feed Description: ASP.NET and More...
As I look back at the last couple of entries, I notice I have been more focused on the non-technical side of things. It could be because I have been pretty involved with projects recently where virtually all the problems were of the non-technical nature. And of course, I have been reading through the Career Programmer book mentioned here.
One of the things that have me thinking about this is a current project that, from the beginning, seemed a little ill conceived. It is too complicated to go into details (and mostly beside the point) but suffice it to say that what the customer wanted is a system that I, as a developer, know is prone to both significant general failures, as well as being incredibly prone to user errors. The system requires the user to be perfect, as the system defines perfect. For instance, the first 4 characters of a patient's last name cannot contain a hyphen. Well, normally that is not a problem, but it certainly could be. Imagine Sara Lo marries Joe Schmo. Her last name, were she to use both names, would be Sara Lee-Schmoo, causing the program to use "Le-S" for the first 4 characters of the last name, and thus falling over and dying.
Years ago, I worked for a company that produced a famously fragile program. The company developed extensive documentation for their product, detailing how you needed to dot certain I's and cross certain T's (but not others!) and the support staff became quite good at making sure the customers knew how inadequate their grasp of the program requirements were. I was at one point working on an installation program, and knowing the program as well as I did, I did not allow the end user to set the folder where the program would install, because I knew that if it was not installed in a certain folder, it would not work. It could be on any drive, but the directory structure was cast in stone, and there was no way for the end user to change it. I was called to task for this, and defended my position bravely. In the end, the folks controlling things still wanted the user to be able to install the application to whatever folder they wanted, giving the user a "freedom" that they had not had before. I called this "the Freedom to Fail". In the end, they allowed the program to be installed as I had planned. But it was a tough battle.
As a professional, I consider it my duty to try and create the best possible program for whoever is paying for the code, be it an employer or a client. After all, I have some training, and more importantly, lots of experience creating systems that work, are flexible and resilient to failure. Unfortunately, for a lot of reasons, that is not always what folks are willing to pay me to do. They have reasons, often simply coin tosses, often based upon some business need I do not understand, but I do feel it is my job to point out to the person requesting the software what I, as a developer, think should be done. Going back to the example above, where the names with hyphens would cause the program to fail, this was one of perhaps a dozen or so problems that would either cause loss of data due to unusual circumstances, or other sorts of failures caused by users not being perfect. You need to know that this is a client that I personally like, and just as important, one who consumes (and better, pays for) perhaps 20% of my time. After a phone conversation with a lower level person who understood my concerns (but was unable to change anything) I composed a lengthy letter (longer than this Blog entry) detailing all of the problems that I anticipated, and what solutions I offered. I considered all of my solutions to be entirely reasonable, and expected that for all but the admittedly unusual cases that would cause loss of data, they would go my way. Not so fast. The client's reply started as follows:
Doug,
Your points are valid and on target.
Of course (and you knew this was coming) he then went on to say that he wanted the system as originally specified, and he was aware of the potential for problems, but he and the end user were convinced that no problem would occur. Sigh.
I was stuck in a waiting room the other day while my daughter got some tests run, and in reading Career Programmer, came upon the following passage, which I will need to remember whenever this situation comes up again (and I am sure it will). The author talks about working on a system that, just after completion, was set to be replaced by a totally different system that was implemented primarily because it was in vogue.
We should note a couple of important points from this example. First of all, it is obviously incredibly wasteful to implement a system, field it, train the users in its operation, and then immediately scrap it just to do the exact same thing on a different platform (and for no other reason than to be trendy). However, that's not my problem. I'm hired to write software, not to manage companies. Furthermore, if they want to pay me twice to write the same system, my bank makes little distinction when it comes to the deposits. In other words, because it is not my company, choosing which programs to implement or what their requirements should be is not for me to say. If I feel strongly about the matter, I need to quit and start a company on my own. Otherwise, it is my duty to implement the decisions of the people who hired me
Oh, and back to the company I mentioned previously in this blog entry, the one that wanted it's fragile software to be able to be installed in any folder, even though it would only run if installed in a certain way. Through the many battles I had with the managers of that company (two of whom were the original owners of the company before it was bought out for a huge sum of money in the IPO boom of the late 90's) whenever I felt myself becoming self righteous and superior to these folks (who I liked a great deal on a personal level, but whose technical skills I did not respect for the most part), I corrected myself with the following phrase:
Previous Topic
