RADBlog

There are times when you get a bad customer.  Fortunately its rare.  I’ve one person who works for one of my clients who is very valuable to that company.  I was working with the client to implement a piece of software.  Of course, I tested it very carefully and fixed what I found. Confidence is high on my part.  All designs are fantastic until it encounters a user.  There are many things that go wrong with even the best work.  First and foremost is the learning curve.  All new software have learning curves. If a user reports a bug, is it learning curve or a real bug?  Users are very capable of finding bugs.  Where they most likely fall down is reporting the bugs to a developer for repair.  Again, that is a learning curve.  And its your responsibility to educate them to help them help you.

This person I mentioned is not a bad person, he’s actually a very decent person.  But when he finds a bug, I tend to fix it very quickly, often in mere minutes.  I take pride delivering that speed.  This person will then check up on the status and I report to him that it is fixed and on the server ready for updating.  He’ll do something very unexpected:  “Who’s fault is it?”

Huh?  The bug is squashed and handled.  Its done and over with.  Why is he looking for someone to punish?  I can understand this viewpoint if its a type of bug that keeps coming back in various forms.  That means the developer has not learned how to avoid such coding errors so they do keep coming back.  But a simple one-off type bug?  Nothing catastrophic or even a bug that prevents one from using the program (aka “showstoppers”).

These types of users are difficult to deal with.  They make conditions difficult to make fixes and get quality testing done.  We all know users can find all sorts of bugs as they will almost always use the program in a way a developer never envisioned.  This is why an ideal tester is one who did not code the program.  After every fix they look for someone to shoot out of a cannon.  They are missing the big picture.  That being that bugs fixed means a better program, one that the company they work for can do a better job.  They are certainly not helping the company this way and they cost their own company extra money when a developer has to chase something up as they often are being paid by the hour.

So when I appealed to the owner of the company about this situation, he had a talk with him.  That certainly improved conditions until I found out that he began hoarding bug reports.  This is where you get someone waiting until they get a nice big list before reporting them.  Or more likely in this case, “smoking gun evidence” the program should not be used.  Now you have a user who is solidly counter-intention, the worse case scenario.  Now what do you do?

The handlings vary.  In my case, I again appealed to the owner that such an activity means that real bugs remain in the system and if left unhandled could cause data corruption (wrong calculations, balances that should equal zero are not zero, etc). It also means that he could approach other users in the company and prove why the new software should not be used.  Such people are clearly an enemy, yet from your customer’s viewpoint, they are a valuable asset.

The wrong thing to do is complain about how awful Joe Schmoe is, even when its true.  What does an executive want on his lines?  He certainly does not want a new problem, or more accurately, a new problem that their juniors demand their bosses handle.  Never do that.  Instead, report a problem and provide at least two solutions to it.  The exec then can pick which one he wants to do, or is free to devise on of his own.  Either way, the junior (or vendor in this case) is looking for solutions and thought the matter through.

Despite this problem, my dealings with this customer means they paid all their invoices on time.  I’ve never had to wear the collection hat with them, despite a clear enemy (towards me) exists inside this business.  They are using the program I built for them to run their business.

I really would recommend subscribing to Mark Riffey’s blog as he has many posts a week on general business, this is only my first. ;-)

This is a very unusual blog as I want to keep it about Clarion development.  This is an exception.

I admit it, I'm very busy.  You would not believe the amount of work on my lines (and glad to have it).  So is my posting a blog wasting my time?  Not really, communication is never really a waste of time.  I don't even consider my assistance to others in various newsgroups a waste of time either.  So what is?

Having to spend my morning scanning in statements and getting them sent to my accountant for tax purposes.  So far this year, I think I've spent about 25 hours organizing things to get last year's taxes filed as required by US law. That is 25 hours I'm not billing. Not to mention the money I must spend complying with complex tax laws.  How complex is it?  Ask our current President why many of his first picks for his cabinet had to withdraw their names.  Tax problems.  I'm thinking, if these nominees are supposed to be the best and brightest and they have tax issues, how are the ordinary citizens supposed to do their taxes?

Its even worse, the Chairman of the House Ways and Means committee (who writes all these tax laws) has issues himself!  And he's not alone, many members of Congress have problems complying (I'm assuming there is no criminal intent - seriously).

You've probably read many news stories about how how many billions of hours and dollars are spent each year complying with our tax code.  And with a recession in progress, our workforce cannot afford downtime.

The question not asked on a national level is simple: Isn't that enough evidence to reform our tax code to something simpler and not waste so much time and lost money?

Back to the regular Clarion blogs.

I've a link to Mark's excellent business blog to the right.  Check out the blog entitled "Ignore customers at your peril".  This had me thinking about software design, all the little things that drive me crazy when I'm the user of someone else's software.  Mark mentions the flight tracker quite a few airlines use.  His description has me convinced this is the same program used at British Airways and Qantas, two of my favorite airlines.  I like that little tracker tool.  But it has some annoying quirks as Mark points out.  I really don't want to see Spanish nor the metric system displayed on this.  And why does Spanish seem to always come up regardless of language used?

I design and code a lot of business software.  To me, it would not be much effort to allow a passenger to select (I mean really select) their preferred language, a choice of imperial or metric measurements and then start the program.  No more translations or conversions.  Also, seems to me, my preferences display the least amount of time.  It may just be the annoyance factor that I have to put up with a system that is meaningless to me that makes it seem to display longer.

Then I started thinking about other examples.  Web applications are commonly designed very poorly.  So common, I really hate using them.  For example, ever go to an order page and get notified you made an error?  Why display the error when you submit the page?  Why not use some validating JavaScript that executes once you leave a control?  And here is where my annoyance starts rising: why do some sites only tell you about one error?  I will concede most sites are getting better here, they will display all errors encountered on the page.  But then they take five steps backwards when they clear out entries that were fine before?  A user has their attention directed at the problem entries during the page refresh to display the error(s).  So they press submit again only to get a new error message that the credit card number or address or phone number is a required field!  I've left sites for less offenses.

I'm hoping that with Clarion# (and its code generating templates) that I can build solid web applications that are easy and fast to use and don't get in a user's way of getting something done.

We've all been told it is not OK to be selfish.  I'm making an exception.

Less than a week ago, I released a new build of the List and Label templates (with some revamped classes).  All this week I've been working on making the templates more efficient.  As of today, there is nothing beneficial to those who've order the templates.  Sounds like a contradiction, doesn't it?  From a customer viewpoint, this is disappointing as nothing new arrived.  From a vendor's viewpoint, this is making future support easier.  Let me explain.

I spotted in the templates that there is a lot of duplicate code.  By that I mean a lot of global settings and options are (and should be) overwritten as the developer would like.  It depends on the circumstances and the developer's design (usually based on his customer's needs).  If the developer's client wants a report always printed to a certain printer with no preview (as in the case of specialty labels that only one printer can provide) it makes sense that a local procedure become the exception to the rule.  So it makes sense that a local procedure be the exception to the rule.

In every procedure where a List & Label control is populated, there should be options to override the global defaults.  So what does that mean to me?  Well, if the local defaults have the option to override the defaults (whatever they may be), then its beneficial to the developer to check a few boxes here, unchecked other boxes there to make this procedure different, an exception to the global rules.  For me the vendor, it means less template code since I can be clever in showing these options.  It means I have only one place to maintain the local overrides.  To my customers, the developers who are placing List & Label in their applications, they simply have option dialogs that inherit the global defaults and can change any of them as they see fit.

Win-win.

It also means that the less template code I have to maintain, its easier to support existing features as well as fix problem areas as well as add new features and functionality.  It means I keep my status in the Lazy Programmer Society (of which I'm President and Founder) and by extension, so do all of my customers.

Its just a philosophy I can apply and my customers get the benefits and no downsides.  That is what I call a "win".

Many moons ago, I had the List & Label classes linked in with the ABC ErrorClass.  Why?  List & Label has its own error messages, and the error block I made for it makes for easy translations in the future.  A few simple tests back then showed that it worked and all the normal ABC error messages were also active.

One of the things I had to do was move some functionality out of the templates to the underlying classes.  The reason for that is despite being clever with some techniques of template coding that to the best of my knowledge, only I've done, it was not working as I expected.  Two different instances of a derived class were either getting mixed up or not generating code the way I expected.  Either way it made for a either a non-compilable program or one that did not work.

The class work for this appears to be done, but its never done until you test it so you can prove it works.  A very simple test is to make a hand coded project.  It was giving me all sorts of errors from List & Label.  OK, so go back and review Combit's documentation on their APIs.  Everything seemed fine.  Cue head scratching.  OK, so where was this error coming from?  Combit has a a Debugview-like debugger which I really like.  Yet it told me nothing I did not already know.

Fire up Clarion's debugger (yes - THAT debugger).  Its quite useful for finding which line of code is not working as expected.  Imagine my surprise, when it told me the line of code that failed was not the one I had my attention on.  It was the next line and the error message thrown by the ABC ErrorClass was indeed spot on.  That's when I found out I had a real duplicate variable on the parameter line (and it had no value since this was the first time it was used).  Well the method call one line above used the different spelling of this variable, quick correction and voila!  No more error messages.

Next time, listen to the error messages, especially those that are validating type messages (must have a value of ...).