How to ignore customers

No news is good news, or everyone hates you and is creative with workarounds

You grew up in the Unix tradition. The college you went to had these large Sun SPARC machines, and your first experience with real programming was writing C on these machines. You heard of the Unix Philosophy during this phase.¹

These ideas have helped to guide you throughout your career as a software developer:

• Write programs that do one thing and do it well.

• Write programs to work together.

• Write programs to handle text streams, because that is a universal interface.

• Beards.

Although you might not hack on Unix every day now² , you have internalized many other Unix conventions³. One of them is no news is good news⁴.

For example, if you tell bash to search all files for the phrase “Purple Monkey Dishwasher,” and it doesn’t find it anywhere —it just return nothing. If you then get frustrated and tell it to remove all files from your external hard drive, the one with all the fan fiction about Richard Stallman, it does it and then just returns—nothing.

$: ./calculate_meaning_of_life 
$:

$: cd /family_photos
$: rm -rf *
$: 

You aren’t consciously aware of it, but you internalized this idea, and it has affected how you operate now that you are not just writing little C programs but are building a software company.

The harmful idea is: no news from customers means good news.

If you ship a new release of your flagship product, RMSAccounting, and don’t hear any screaming, it must have gone well. If it doesn’t seem as if any bugs have been reported, even though the software was a major rewrite, then this means that there are no bugs. Zero bugs; time for a party!

When a bug report finally comes in, you and your team don’t always believe it, and say things like the following:

• How are they using the software when they get logged out every hour? That can’t be.

• If that integration was broken, wouldn’t they have noticed? It has been two weeks, and none of their reports are updating automatically.

• This must have been broken for months; there is no way.

You have a simple view of your users; you think that they operate like this pseudocode:

public void useSystem()
{
   if (howThingsWork(today) != howThingsWork(yesterday))
   {
      throw new CallVendorException("System no worky", AngerLevel.Low);
   }
}

This is not true. Your customers are busy, possibly drunk, and regular people with complete lives. Regular people who don’t sign up to sit in front of a computer for most of the day have been conditioned for years that it is their fault when a technical problem arises. So they try very hard to get around it. The lengths to which they go are amazing.

The code they are running is more like this:

for (int i = 0; i < AnInsaneNumber; i++)
   useSystem();

usePaperSystemWhileCursing();

public bool useSystem()
{
   if (howThingsWork(today) != howThingsWork(yesterday))
   {
      logoutOfSystem(Times.3);
   
      feelEmbarrassedAndStupid(Minutes.15);

      goEatLunch();
      goGetCoffee();
      
      rebootComputer(Times.3);
      rebootWifiRouter(Times.3);
      
      logoutOfSystem(Times.3);
      
      startSmoking();
   }
}

Commentary

Users after 20 minutes of usage of your latest release

Users are very persistent; I am constantly surprised by them. Because you work on something, you lose sight of how it fits into your average user’s day. Closing that gap is a clear goal to building better systems.

My three examples above:

How are they using the software when they get logged out every hour? That can’t be.

Users will do things that will annoy a programmer to no end. Using a system you have to log back into 10 times a day is not an annoyance to everyday users. They will put up with a large amount of friction. If they have to use your software, they will deal with it.

Do you remember when you were young and had to write your first complicated paper in Microsoft Word? Maybe it was your resume; you needed columns, fancy headings, and other things. How long did you spend on it? It took an insane amount of time. Microsoft Word is not what you were working on, but your resume was. And you kept at it until it was done, even if an engineer who works on Word would have known how to do it all much more quickly. What would you do if a new version of Word came out and changed or broke a bunch of stuff? That’s right, deal with it.

If that integration was broken, wouldn’t they have noticed? It has been two weeks, and none of their reports are updating automatically.

Sure, it wasn’t updating automatically, but if you have less than 50 reports and you can hit a refresh button, a person will likely hit the button 50 times daily to get their job done. If they keep doing this for weeks, it will no longer feel like a burden, and they might keep doing it. Their job is not to have the system work effectively but to get their task done. This is one of the reasons the Jobs to Be Done framework is a nice lesson: keep your eyes focused on that same goal to build great software.

This must have been broken for months; no way

This is the most frustrating because it makes everyone look and feel stupid. If customers have told you about a Very Big Problem, and you have done nothing about it:

• not fixed it

• not shown a roadmap where it will be fixed

• not explained why it would be hard when it seems simple

• not asked any questions about it

Eventually, they will stop talking about it. This is their reality now until they move to another software vendor. They will not continue to complain consistently. People are not deterministic automata; they become frustrated and experience urgency in which short vs. long-term decisions lead to them just getting the job done, even with your crappy software. Users are not grep.

1. You might think that a system has to be pretty complex to have its own philosophy, but this is not true. My EPSON printer has one, which it embodies in both software and hardware: “Death to David (DTD)”

2. You don’t consider cygwin or WSL or Mac OS X real unix, for reasons that nobody but you and Richard Stallman care about. You don’t like the term *nix in the same way you don’t like the term Full Stack Developer.

3. If I can suggest something not from Unix to internalize and use in your personal life:

Be liberal in what you accept, and conservative in what you produce

4. Ok, the real rule is:

Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input.

which nets out to programs being terse, not verbose, because outputting something like “no results found” to stdout would cause another program to use that as stdin.