Blaming the User

My favorite super-pattern in developing and supporting software.  Always assume the user is wrong.  Remember, you are User Number Zero, so… blame yourself.

Screen Shot 2018-07-08 at 8.51.40 AM.png

Defensive Programming is a technique similar to Defensive Driving. Always assume the user will break your program. Defensive programming will save you time in the long run by reducing support and increasing user satisfaction.

Its aim is to reduce the risk of collision by anticipating dangerous situations, despite adverse conditions or the mistakes of others – Defensive Driving – Wikipedia 2018

We must have a balance of making programs flexible enough to allow the user to use it for intentions unforeseen by the tool-makers themselves, and to ensure they don’t fall off the rails and lose data because they entered a word instead of a number.

Input Validation

  • Never trust Input Text Boxes
    • Always convert numerical values using ParseFloat or equivalent
    • Never  Eval() or Shell() with input string
    • Never use string to build SQL Query without proper escaping. see SQL Injection
    • Always trim whitespace at beginning and end of string
  • Give clear and actionable error messages when providing feedback to user on their incorrect inputs
  • … This post could go on for a while, TBF

 

Further Reading

Shipping a Beta

So you have done a demo of your application and your users want to use it for themselves.  How ready is your project to move from barely working prototype to an actual product?  Demos are deceiving.  Remember you only take a picture from the pretty side.

To be able to ship the prototype to beta is a huge step and sometimes can take too long.  Every day that goes by that the product isn’t in a user’s hands is another day without oxygen.  You are swimming further and further from the line.  Toe the line and ship that beta no matter what.

Some Questions to Help You Get Started

  • How does the user install or get your software?
  • Do you have a quick start 1 page tutorial or guide on basic usage?
  • Does it work in your user’s environments?
  • Does it really solve the users issue?
  • How often do they use it?
  • How fast can you ship another beta to fill all the holes they are sure to run into eventually?

Demo or Die

The amount of information conveyed with a picture is said to be worth a thousand words. What is the information density of a demo?  Pictures, flow arrows, and hand waiving can only get you so far.  Demo or die, or sometimes… demo and die.

5b6af7b0-efd9-4d94-b7d7-3319270f2662.jpg

Don’t you love it when someone in audience gets smart and tries to move you off script… the movie magic ends real quick.

There is something about the medium in which you can poke and paw a slider or a button and have something update in realtime.  It either works or it crashes and burns.  A working demo is the baseline test of competency, but the only problem is can the demo make it to 1.0?  Shipping software is incredibly hard and the history of PowerPoint 1.0 is facinating.

In the early days they had trouble convincing people of what PowerPoint was and what problem it solved.  Their mockups were impeccable.  The amount of planning and discipline of these 1980s software startups is inspiring.  Sweating Bullets is on the must read list for anybody who studies software development.

Suggested Reading

PDF of Sweating Bullets by Robert Gaskins

Screen Shot 2018-05-15 at 9.13.21 PM.png