Who’s Your User, Daddy?

All software is developed to be used by someone, even if only in an automated fashion (that is, without any direct interaction with the user). As such, it is important to understand who your user is, or you may (ok, probably will) find the going tough. If you are a game developer, life is good. You know who your users are – gamers! Likewise, there are many industries or types of programs where the user is a well-known entity. If you write accounting software, for example, your user is probably someone who does…uh…accounting.

I happen to work in an environment where the real user of the software is often a bit of an unknown. Well, the real user is generally known, but often we are unable to get direct feedback from the user, or the feedback loop is very tenuous and arrives filtered through other people who generally are not developers and rarely elicit the right kind of feedback or ask the users the right kinds of questions. The situation can be so backwards, in fact, that some of the developers I’ve worked with over the years are convinced the user is, in fact, the middleman who filters all that rarified feedback. Developers will say things like, “I’ll have to talk to the users about that.” Of course, they’re never going to talk to an actual user, just the business people who are in control of the project. In the real world, these people would be called stakeholders, but even in other companies, I’m willing to bet that the stakeholders are actually treated as if they were the users.

Stakeholders may feel they have deep insight into how real users will interact with the software, but, unless they spend a lot of time with real users, they are typically just guessing. That’s bad enough, however, the real problem occurs when the stakeholder has a vested interest in trying to shape the software to make their own job easier. While that’s understandable, and their opinion does matter in that respect, it doesn’t serve the actual user of the software. A common symptom of this affliction are screens that fit the stakeholders workflow, rather than the end user’s workflow, or forcing the end user to enter all kinds of data that may not be readily available to them. The stakeholder wants every possible piece of data up front, whether they truly need it or not, and these become required fields. End users will frequently come up with creative ways to get around the restrictions, which ultimately helps no one, because it ends up being extra noise to filter out.

Unfortunately, developers have no say in any of this, and most will simply do as they are told. I’m not sure what can be done to change this attitude, but it’s ultimately counterproductive, and developers like that end up revisiting things over and over as they try to tweak things and plug holes – problems that might have been averted by paying more attention to making sure the software actually was developed for the right user.

4/10/2014 Article Links

Joke:

A young man in his early twenties drowned earlier in the day at a public swimming pool. Police determined from family members that the man was a computer programmer. They also interviewed several onlookers who seemed to be unaware he was in any trouble. One person’s response was typical. She said, “He just kept yelling F1! F1! No one knew what he meant.”

 

Funny video:

The Expert (The project, place, and people involved may be different, but all developers have been in this meeting)

 

Security stuff:

Low adoption rate of HSTS website security mechanism is worrying, EFF says (What in the world of tech security isn’t worrying, these days?)

Repeat after me: Model your security threats first (Think of it as TFD – Threat First Development)

Researchers disclose vulnerabilities in Oracle Java Cloud Service (Cloudy Java…not good)

Businesses face rising political pressure from data breaches (gee, ya think?)

New Windows Phone security necessary, but not groundbreaking (making WinPhone more enterprise friendly)

 

Web development:

Visual Studio extensions for web developers (lots of stuff for all web developers)

Vaadin switching to C# 

Web developers less concerned about browser-compatibility, more concerned with HTML5

 

Mobile development:

5 things every beginning Android app developer should know (probably applicable to any mobile app developer, too)

Windows Phone comes to the enterprise

App development quicker on Android than OS rivals – survey (of course, it all depends on what you’re trying to do, and how much experience you have…)

Hybrid Web Applications: The Best of All Worlds for Mobile Application Development

Microsoft’s smart strategy to take on Android

Following Famo.us, Ludei takes a swing at PhoneGap too

 

F# stuff:

A C# developer’s take on F#: Discovery to Production

F# Data 2.0.5 (new version)

Domain-Driven Design Using a Functional Language (not just about F#, though)

 

Other stuff:

The Reasons Businesses Use Open Source Are Changing Faster Than You Realize (moving at the speed of greed)

Jasper (Jasper is an open source platform for developing always-on, voice-controlled applications)

Salary Survey 2014 (as always, your mileage may vary)

C# 6: First reactions

Andromeda: Google’s Secret Weapon To Keep Amazon And Microsoft On Their Toes (the new Andromeda Strain?)

Contributions of Individual Programming Languages to Software Development

YourLanguageSucks (see how your favorite programming language fared)

Microsoft’s Trunk Based Development (No, nothing about elephants. Sorry.)

Wanna Build a Rocket? NASA’s About to Give Away a Mountain of Its Code (Literally a mountain! It is chiseled in stone! Just kidding! That would have been too hard to insert into the punched card reader.)

Don’t want to mix programming languages? You already do!

Zen and the Art of Tech in the Valley (Oh, great. New Age Driven Development…)