Sunday, August 30, 2009

Truth in Dilbert (like we're surprised) - Diversionary tactics

I am happy to say that the following Dilbert cartoon is legitimately linked to the Dilbert.com site. I just noticed today that they allow embedding of the strip. Why am I happy? Because there are wonderful lessons to be had.

Today's Dilbert is something I see all the time. The joke here is management, but I see it from developers too. Basically imagining the worst possible outcome. Of course there is the opposite, imagining the best possible outcome.

The problem is critical thinking. Most people can't do it anymore. You need to examine critically the statements made to say it is bullshit or not. Of course it helps that the person making such statements isn't either a complete rube or has some other evil (or accidentally evil) intent.

Why would people say silly things that are either massively pessimistic, FUD but also mind blowing optimistic? Sadly it isn't because they are clueless, but they are just diversionary tactics. It is not that something is impossible, they just don't want to do it. It isn't that adopting a new language or technology is easy and spuper productive, but it is cool and would look good on a resume.

Remember the old saw: Don't assume malice when simple stupidity will do. Well, here is another one: If they really aren't that stupid, there is another reason why they 'sound' stupid. Sadly this 'sounding stupid' is pretty deep. To say something stupid, you have to commit to believing the statement. That means endless argument as facts will be ignored.

The human brain is a messy place.

On to the cartoon!

Dilbert.com

Friday, August 28, 2009

Check Your Blinders at the Door

Here are some bad words:

  • Tunnel Vision
  • Blinders
  • Arrogance
  • Single Mindedness
  • Happy Path
  • My Opinion
  • One Way
  • One Solution
  • One Method
  • Only

These are very bad words because they all lead to software failure. Simply they lead the developer into false beliefs that the code is complete and meets user needs.

  • Think like a user, not how you would use it!
  • Happy, Unhappy, Alternate Paths
  • What could go wrong?
  • Can the user make a mistake?
  • What about Undo/Redo, s the action symmetric?

Remember that the most critical bug is that the user will not use your software. If you cause extra work for the user, inconvenience them, waste their time, or treat them as stupid drones, you will not be considered a great programmer.


Sunday, August 2, 2009

Error Dialog? Think twice!

A lot of developers pop up dialog boxes to report errors. But why? The fact is that there are three types of error:

1) An error by the user that needs to be corrected.
2) An error unexpected by the developer and announced for debug purposes
3) An error that occurred, but is corrected. Often reported as part of a debugging the capability, and left in the code.

Warnings and errors are usually the same thing, but just a level of severity of an error. So assume we are talking about both.

The problem with most software is that the errors unpredicted by developers often are reported without any information to help isolate the error so that it can be corrected in code. We have all seen it, a confusing error message and usually diminishing functionality because the error makes the application unstable, corrupts data, and makes the application behave like it has gone insane.

The worst thing about the class 1 errors is that if you call support, the first thing they ask is, "What were you doing just before you saw the message?" What a worthless statement. Most people are not memorizing every step prior to an error. It is one of the world's most silliest questions.

I am sorry, but you need debug info. You can't interview customers. You need to build in the ability to report errors in a rich way to allow recreation and/or isolation of the issue.

Data to Report for Errors

What information? How about the log, the user's files, and here is a breath of fresh air: The undo/redo stack. The undo/redo stack is in many applications already. The only job is to serialize the data to allow a developer to understand what the user did 'before' and error.

The commands in the stack may not isolate the exact issue, but it can narrow down the activities. It should be required by all development organizations that the undo/redo stack be serialize-able and even repayable to recreate errors.

Rules for Error Dialogs

1) All errors (and warnings), should have a way for the user to report to developers. That includes errors made by developers. The fact is that even user errors can be a result of bad design. If you get a disproportionate reporting of user errors, your application probably needs a redesign.

2) No generic message dialogs! They just ask for trouble. You should have
a) A reference to the part of the code the error was generated from.
b) A short sentence to describe the error
c) Any related data, like the type and object instance identification where the error occurred.
d) Information on how to correct the error
e) If possible, undo the action that caused the error
f) Ability to report the error to the development team

3) Don't report status with dialogs if you can avoid it. The fact is that dialogs are at least an extra click for users to waste on dismissing a dialog.

4) Reporting an error that you have corrected is also a waste. Often such dialogs remain in code because the developer likes to see the result of hard work. Users don't care, so these dialogs must be forbidden. Even logging this sort of thing may be a waste of resources.

5) If you can, auto report errors back to developers. The simple fact is that developers will successfully ignore user problems unless you have the statistics to prove code is broken. Usually only users see errors as developers don't behave the same way and don't encounter such errors. It is therefore imperative that such data be reported to developers to close the loop. Do it electronically to avoid wasting everyone's time, money, and effort.

All Dialogs are Criminals Until Proven 100% Necessary

The simple rule of thumb is to avoid dialogs in many cases. This is especially true for errors, warnings, and informational dialogs.