Coded into a Corner

Creating software is easy, creating software that is sustainable to maintain and extend is hard.  There are not many mediums in which the consequences of a simple change or design decision can render the complete system useless.  The way in which the software is built is just as critical as to who is building it.

Honey why is the toilet flushing now when I flip the light switch?

Whoa! Cool! I didn’t realize changing the light bulb would do that.

Poorly designed systems are interconnected in ways that are not necessary.  It is often easier to write the prototype in this manner, but products often need to be refactored to use time tested design patterns.

If you ever find yourself scared to change something or can’t figure out how to add the next killer feature.  It is certainly time you reevaluate what you have and don’t be afraid to delete your code.   You may be surprised how much of it is no longer needed.

More code, more bugs!

Recommended Reading



The Weekend Thrash

So you think you are almost there. You think one or two more hacking sessions could “do it” and you start the weekend thrash.

What is the difference between a clever hack and an unmaintainable pit of tar?

If you are in the Zone, then you of course nothing can stop you.  But I say stop and rethink your life.  You probably are building the wrong thing anyway.

I don’t roll on Shabbos!




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.


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