🚀 go-pugleaf

John,

Your statement reflects a common mistake.  If a programmer writes material without
properly understanding the "business" underneath, then the end result is something
that technically matches what the programmer thinks is required.  This has nothing
to do with whether or not the system is useful or useable in the real world.  What
if some idiot places the delete key beside the insert key (look at you keyboard)
and doesn't verify deletes, for example?  Yeah, well, thats user error, its not
my problem.  Wrong!

As a programmer, your problem is ANYTHING that adversly affects the usability of
your product, that you have the power to alleviate.  The algorithms used are too
slow, multiuser edits cause problems, if the power fails there is no way to 
recover, didn't check that memory was really available during malloc, force the
user through a technically correct procedure that could be simplified, source not
well documented and maintainable.  These are all examples of problems that the 
programmer should communicate and attempt to fix before delivering a product.

Unfortunately, the real world is a very dynamic and complex environment.  It isn't
anything like what they teach us all when we are fledging wannabe programmers.  We
learn that concise rules can be used to solve these situations exactly, and that
step 2 must always follow step 1.  However, in our real lives, we do whatever steps
we choose, in any order, if we do them at all.  It is wrong but common for the
programmer to assume the users are stupid, and blame them if they don't go through
the correct hoops.  We must leave this era behind.

Something basic that I have not even bothered to touch upon, is the arrogance of
the programmer to assume that they understand the hospital administration business
better than hospital administrators.  What a programmer (analyst, whatever) does
understand is the capabilities of the technology.  They understand that new ways
of doings things may be possible, in some instances.  By properly communicating 
with users and management, it can be reasonably decided which items represent true
improvements, and which are technical items that are not useful to the business.

Whether or not the programmer needs to communicate with the end users depends upon
whether or not somebody else is able to communicate with the end user and the
programmer both effectively.  Programmers can be very hard people to communicate
with, as they are ensconced in technical material, terminology, rules, and even
prejudices.  Not to mention that many have trouble with english, or with human
interaction as they can epitomize geeks.

When I first started working, I had terrific managers who had a forward thinking
mentality, and I pay silent homage to them every day.  Mr Haley and Mr Haxton, by
name, reminded me everytime I tried to take a shortcut, every time I tried to tell
someone something wasn't possible because I didn't want to do it, every time I got
annoyed with redoing something yet again, every time I thought something wasn't
possible because I didn't know how, that the only important thing is that the user
of the final product likes it and uses it.  Will they like it if you leave it this
way?  No!  Well, think about it as if you were the user, then spend the time to
make the computer do the work instead of the user.  Inevitably, if you can get into
the right mindset, there is a simple solution to the problem.  Besides, giving the
user something they like is a great boost to your own moral, as they will be very
pleasantly surprised, and you will recieve compliments from all levels!

Regards,

Andrew Smith
Custom Innovative Solutions
http://www.cisc.com/

P.S.  Phew, sorry for the diatribe but I am so tired of working with people who
      deliver crud and think they are doing a good job... they should be teaching
      attitude as well as technique.

John Joseph Newbigin wrote:
> If a hospital administrator wanted to write some hospital administrator
> software, more than likly what they would come up with is a copy for the
> current system with a new user interface.
> 
> If a programmer wanted to write some hospital administrator software then
> thay would start with no knowledge of the current system so the result
> will not be the same as the original system but a new and hopefully
> improved way that will hospital administrate better than the previous
> system.