Login issues on Laptop

[Chemlak]

Thanks, as always, Rob.

 

[ibecker]

Well said, Rob. I've been Systems Administrator/SRE for 16 years, working at several different companies with hundreds of colleagues. I completely concur with the "purple unicorn" theory - engineers typically write awful user-facing documentation (including error messages), if they write any at all. It's such a problem in the industry that there's an entirely different job description ("Technical Writer") for the people who translate "engineerese" into [natural language of your choice]. Unfortunately, tech writers are a luxury that most small companies cannot afford. Even in companies where there are tech writers, the process still requires a great deal of the engineers' time as well, as they describe their work to the tech writers for "translation".

Think about it, folks - if LWD could easily create perfect documentation, they definitely would. After all, at the very least it would cut down on the support burden of answering many of the users' questions. However, it's a much harder (and more expensive) problem than it seems from the outside.

-Ian

 

[MaxSupernova]

Purple Unicorns. The theoretical "spherical cow".

Well said, Rob, thank you. I appreciate your candor.

I am in the middle of a multi-million-dollar multi-thousand-man-hour re-engineering of our entire support process, and pretty much the primary push is better user-friendly error reporting and user self-sufficiency through thorough documentation and self-guided support.

So, not only am I primed to be going there, I'm also pretty tense about it. It's my entire life right now. I got tunnel vision.

I know from experience the absolute worst thing a coder can deal with is a user who thinks they know better. I'm sorry for being that user. :-\

Carry on.

 

[MaxSupernova]

Think about it, folks - if LWD could easily create perfect documentation, they definitely would. After all, at the very least it would cut down on the support burden of answering many of the users' questions. However, it's a much harder (and more expensive) problem than it seems from the outside.

I do want to address this, because it's a common myth. Not specifically dealing with Realm Works, but the industry in general.

It's more expensive (much more expensive) to deal with it afterwards than it is to alter the culture to create proper error reporting and documentation at code generation or testing time.

Even putting documentation aside, it's cheaper, simpler and saves far more time to create your error reporting templates and messaging as user-friendly and plain english from the beginning than it is to just use "programmer codes" and change it later. It *never* gets changed later. Ever.

It's a cultural shift that lots of people in the industry are trying to push for in training new coders, but established coders seem to have have a "thing" against documentation or error reporting.

If you can convince your coders to document, even minimally, and at the very least report errors and exceptions in understandable terms, your product is head and shoulders above 99% of others in terms of supportability before you even release, at the cost of essentially nothing. Everyone can find 2% more time to do that, yet no one can find an entire new project's worth of budget to do it afterwards. Your code is easier to document, your code is easier to support, and your time spent harassing your coders to do tech support is reduced greatly because they aren't needed to interpret errors and exceptions. They get frustrated when they get called to answer questions, but if they had documented in the first place it would never have to happen.

 

[Aaron]

4. Programmers write software. They do it well because their brains work a particular way - one that is very different from the norm. It is arguably quite rare for programmers to also be mindful of the typical user - one developer I know refers to such a combination as a "purple unicorn" (i.e. mythical). Consequently, many aspects of software products are frequently not well handled for the typical consumer. Witness 30 years of products from Microsoft as Exhibit A. So the claim that it takes ZERO extra time to write a clear error message is flawed. If the programmer writes the error messages, then you get a message that makes sense to the PROGRAMMER - which is exactly what we have here. Someone else has to come in and "police" everything to make sure it's all being done optimally for the average user.

Purple unicorn programmer is best programmer!

 

[Lexin]

Your code is easier to document, your code is easier to support, and your time spent harassing your coders to do tech support is reduced greatly because they aren't needed to interpret errors and exceptions.

At least it has an error report which has a meaning, even if that meaning isn't completely clear to the user. I used to be employed by an organisation which ran their back office facility on a huge database which didn't even do that much. If you did something the database didn't like, it just sat there, looking back at you, giving no clue what you'd done wrong but refusing to do what you asked.

Plus, it was an industry standard program. I recall discussing it with a friend who worked in a smaller company to me (mine employed 90,000 staff) and they used it, too.

She told me that she finally assumed that the program was created by some kind of evil mastermind, or Cthulhoid deity, and the way you made it work was to dance in a stone circle, having sacrificed ten chickens on an altar. And even then, it was a less than 50% chance.

 

[MaxSupernova]

She told me that she finally assumed that the program was created by some kind of evil mastermind, or Cthulhoid deity, and the way you made it work was to dance in a stone circle, having sacrificed ten chickens on an altar. And even then, it was a less than 50% chance.

LOL!

I used to work with a program that returned all errors and system messages in German.

 

[ibecker]

My favorite error messages come from the world of Linux/UNIX:

- The 'tar' command (used to create and manipulate archives of files): if you give 'tar' an invalid set of arguments, it will tell you that it is "Cowardly refusing to create an empty archive."
- Linux/UNIX printer subsystems, given a certain set of error conditions, would report 'Printer on fire'! (https://en.wikipedia.org/wiki/Lp0_on_fire)

 

[rob]

It's more expensive (much more expensive) to deal with it afterwards than it is to alter the culture to create proper error reporting and documentation at code generation or testing time.

This assertion is only partially correct, as you've (IMHO) conflated three separate concerns into a single assertion within the overall claim of your post. There's the question of (a) getting programmers to document what they've done, (b) getting the error handling behavior correct, and (c) getting the error messages shown to the user to be clear and helpful to the user.

I wholly agree that (a) and (b) have a profoundly positive effect on the overall product that results. Just ask the team here, and they'll confirm that I preach those two things with regularity. I contend that we're actually pretty decent at (b), since the actual behavior is reasonable - albeit not the messages themselves.

The problem, for me, is you've lumped (c) into the mix. It's my view that (c) does not have nearly the same level of impact overall as the other two. I stand by my statements above regarding the level of importance for (c) within Realm Works.

I must also direct your attention back to item #1 in my post above. In there, I clearly state that I'd already gotten on David's case regarding the error messages themselves. So this is definitely NOT something that we gloss over and don't care about. It just doesn't get policed as well as it could.

Getting programmers to think and communicate like users is HARD. Their brains just aren't wired that way, which is what makes them excellent programmers in the first place! It's like teaching an adult who only knows English how to speak Mandarin. Is it possible? Definitely. But it requires a LOT of re-wiring of the brain, since it amounts to learning an entirely different way of thinking. That entails lots of time for the developer AND for whoever is coaching them in the process. It's incredibly expensive, and the payoff is limited.

This raises the question of whether that huge cost is worth it when compared to all the other things that need to be done on a given project. For us, it's a work in progress, and it's something we try to balance against everything else on our todo list, keeping clearly in mind the priorities that have been voiced by our users.

On this particular point, it seems we'll have to respectfully agree to disagree.

 

[Decrayer]

@rob: Although I agree with you, writing short, clear and helpfull error messages does not come with zero cost, it usually pays out well, because it saves a lot of questions. And if you already do the work of implementing an error message, then you already do some of the work. I'm a programmer myself and I know what I'm talking about. Since I work with other people on the same piece of software, it makes a lot of sense to have meaningfull error messages (and log messages) in our code, so the others can easily find out what went wrong. And that saves a lot of time.

And for my case (just to show you my perspective/reaction), the message "login is not available" just describes a "cause", not the "reason". For me, it was obvious that there can be a couple of reasons for this. The most obvious ones where, that my computer had no internet connection (which I checked first). The second one was, that the Realm Works Login service would be down. But since I was able to login from my other, desktop PC, that wasn't the case either. To be fair, an error message telling me, that no connection could be established to the servers hadn't helped me any further. After I checked the two most obvious error sources, I opened this thread to get help. The only difference between both computers where, that one of them was a laptop connected via wlan and only updated once, the other beeing a desktop and updated twice in the period. But since the error doesn't occur currently, I can't give any more information and the priority for fixing also lowered.

Their brains just aren't wired that way, which is what makes them excellent programmers in the first place!

That sounds wrong to me. Most often, the programmers are with their minds quite deep into the practical technical stuff. When they hear about a problem, they immediately think about possible solutions and start to evaluate approaches. They get "tunnel vision". As do a lot of other people who are deeply involved in their domain. This is normal, their brains don't "work different". It's quite hard, if not impossible, to avoid this tunnel vision. But you don't really have to. You just need to have a good correction process in place (e.g. testers, that report this kind of issues).

So for example regarding the testing messages, you don't need to plan to "go through all the messages" to fix them up. You only need a process that collects ambivalent or bad error messages and fix thoose. Use the community for that. Example: this thread should result in a normal priority ticket to change the error message on the login form. Or even better, create a bug report forum section. That way, people can report bugs and see, if other people have already reported that bug (lowering the amount of support emails your dev's have to deal with).

But ok, enough now, you are busy people. I also want to say, that the whole issue is not that important to me. I know, that people who are not into the developement usually don't make usefull comments because they lack the insight. My suggestions are just as long and explicit because I like your software and want to help, so feel free to completely ignore my proposal And have a nice day!

 

[Parody]

While the error message should be improved to at least suggest some course of action, the deeper issue (to me) is why a single check at startup locks the entire run of the program into not being able to talk to the server. Instead of locking out with an opaque error message, say you couldn't talk to the server and try the prerequisite(s) again if/when the user tries to log in.

(I had much longer versions of this post earlier this week, but this is enough backseat software design. :)

 

[rob]

While the error message should be improved to at least suggest some course of action, the deeper issue (to me) is why a single check at startup locks the entire run of the program into not being able to talk to the server. Instead of locking out with an opaque error message, say you couldn't talk to the server and try the prerequisite(s) again if/when the user tries to log in.

(I had much longer versions of this post earlier this week, but this is enough backseat software design. :)

The answer consists of three critical little letters that I thought we communicated clearly, but apparently not: "bug".

 

[ShadowChemosh]

The answer consists of three critical little letters that I thought we communicated clearly, but apparently not: "bug".

No no its an "opportunity" not a bug...