Is this what Building Software is *supposed* to look like?

There’s a discussion going on The Orange Site about a developer’s Computer Scientist friend who recently tried to use a programming module they found on Github . Ostensibly they were trying to do something anyone might do today, they found a package that fit their needs and tried to figure out what they’d need to do to run it.

I’ve read the comments so you don’t have to, and the discussion centers around the idea that “oh well this is just how things are and if you’re a programmer you should just shut up and deal with it”.

I can’t begin to describe how bad that outlook is for us and our profession, and even more importantly, how that outlook hurts building better software — software that people love to use. Software they find joy in. Software that has a soul.

The empathy needed to understand why your users are using your software, and what they’re trying to do with it is the empathy that makes building good software possible. Without that empathy — without that sense of “putting ourselves in the user’s shoes”, we’re never going to be able to make software that truly changes our user’s lives for the better.

But the preachy stuff aside; what can we take from this? What can we do?

Look at every bit of development tooling you use. What is a joy to use, and what is a pain? If it’s a pain to use, what would it take to make it a better experience for you? As an example, I’ve gone back to powershell, and was trying to get information about a command, and so I tried:

<command-name> help
<command-name> /?
<command-name> --help

And none worked.

Why not? /? and –help have both been methods for getting help for decades — why wouldn’t powershell adopt them? Instead, I have to do:

 Get-Help <command-Name>

Further, why not tell me when I load a Powershell Shell how to get help for commands? Right now all I see is this:

Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.

Try the new cross-platform PowerShell 

PS C:\Users\George> 

Microsoft is advertising something new to me — but not telling me how to use the software that I’m looking at!

Wouldn’t a better experience for me (and a reason for me to look at PSCore6) be to give me a good experience for what I’m already using?

What would it take for this experience to be better? How about this?

Windows PowerShell 
Copyright (C) Microsoft Corporation. All rights reserved. 

To get a list of commands available, type Get-Command.
To get help for commands, type Get-Help <command-name>.

Something not working how you expect? 
Visit in your web browser to get help.

PS C:\Users\George> 

It doesn’t take much to improve your users’s experience with your software, and it starts with empathy.

3 thoughts on “Is this what Building Software is *supposed* to look like?”

  1. For what it’s worth, they know how… 🙂
    Exchange 2010 PowerShell Console:

    Welcome to the Exchange Management Shell!

    Full list of cmdlets: Get-Command
    Only Exchange cmdlets: Get-ExCommand
    Cmdlets that match a specific string: Help **
    Get general help: Help
    Get help for a cmdlet: Help or -?
    Show quick reference guide: QuickRef
    Exchange team blog: Get-ExBlog
    Show full output for a command: | Format-List

    Tip of the day #61:

    Want to view the mounted status of all mailbox databases? Type:

    Get-MailboxDatabase -Status | Format-Table Name, Server, Mounted

    VERBOSE: Connecting to
    VERBOSE: Connected to
    [PS] C:\Windows\system32>

  2. Typing `help` by itself from windows Powershell (the version you are referring to) provides a detailed help screen as you are requesting. `help` is an alias to `Get-Help` and unless you have a script or module installed that deletes predefined aliases, then typing `help` on the command line does what you are requesting.

  3. Funny enough I only ever tried that one on an LOB standard crud app I was hired to build. All the dialogs said please & thankyou, every thing was described, the user knew exactly what was happening, what they where being asked for and why.

    There was absolutely no ambiguity, the app was lovely to use and all the testers thought it was great.

    Then management saw it.

    They where horrified, to polite, to helpful came the replies.

    Then marketing chimed in…

    We have no reasons to improve things, so no reasons to sell new *improved* copies of said software.

    What was an internal app, had been decided without me knowing that it was going to be marketed and sold as a profit making attempt.

    I got told I was a bad developer, and my services where no longer required. The next time I saw the app, the companies forum was full of “How do I do X” questions and reports of things being broken, and the screen shots looked dreadfull.

    As long as software production continues to be market driven by marketing folks it will never change.

Leave a Reply