Developing Respectful Software
We are spending a lot of time thinking and talking about the culture we want to create at DataDIGEST. This keeps boiling down to putting people first: employees, clients, suppliers and the wider community. Whilst this is hardly a unique idea, many companies fail in putting a similar cultural vision into practice. In the next few blog posts I want to unpack how we can make a people-focussed culture a reality.
To kick this off I am going to outline how the software you produce can be a reflection of your commitment to put people first. I am calling this Respectful Software.
Respecting the user
The obvious one. Respecting the users of your software means (at a minimum) giving them something usable which does what they want. If you are producing a consumer product users can vote with their feet and just not use your software if you fail on this point, but in a corporate environment they may be forced to use it. Don’t use this as a reason to not care.
I’ve seen firsthand a couple of epic fails on the usability side. One system colour-coded the background of the screens based on the function the user was in. Unfortunately this meant that one particular user spent his entire day staring at a screen with a bright red background. The second instance was a system where the developers decided that a right to left flow was the logical choice and functionality was hidden behind arcane menu items. To perform one common workflow the user needed to drill down a couple of levels within the menu structure, enter some data, navigate back up the menus to the root and then drill down into another section before returning to the original menu to complete the task. The intended users of this system refused to adopt it until it was forced on them by managerial edict.
Another way that all software should show respect for users is by protecting the user’s data. It really shouldn’t need stating now, but case after case of personal data being obtained in system breaches keep being reported. AshleyMaddinson.com, eBay, AOL, Evernote, HP Morgan Chase. The message being sent out is that companies first work out how to make money out of users and then, maybe, if you are very lucky, they will worry about securing your data.
The take away here is that to create software that is respectful of users you need to put yourself in their shoes. Talk to them, conduct studies, engage experts, whatever works for your budget, but start with a user and their needs and work forwards, rather than identifying a solution and a technology and working backwards.
Respecting ops staff
I have seen a system that took a day and a half to install and required constant attention throughout the process. If a mistake was made you had to rollback to the very beginning and start again, provided of course that you had noticed the mistake in the first place. Unsurprisingly the ops team refused to accept responsibility for this system and it was left to developers (although I might add, not the developers who created the mess in the first place) to deploy every release.
Don’t be this company. Take the time to provide a release package, automate it as much as possible and provide meaningful instructions for the deployment of your software.
Respecting customer support staff
Customer support can get a bad name but I feel for them in a lot of cases. Often untrained and underpaid they are then put in a situation where they are not provided with sufficient information to effectively do their job.
Think about how support will be provided to the users of your system. Now work out how your system can provide the information the support team will need to provide this support. This will likely involve a sound logging and exception handling strategy with additional tools that empower your support team to perform diagnostics. The best approach could well be one that allows the support team to proactively resolve issues for users.
Respecting other developers
Ultimately it is highly likely that other developers will work on the codebase. At a personal level we shouldn’t want to make their task a miserable one and as an organisation we don’t want new developers spending days trying to work out how to make changes. Fortunately, with a little thought and discipline we can avoid both and the techniques are well documented in software development literature and should be familiar to professional developers.
First, maintain just enough documentation to get new contributors started. Where’s the repository, how do you setup a development environment, a feature overview, a technical overview, etc. This out of band documentation should be easily accessible and succinct.
Secondly, maintain a (passing) set of automated tests for the system. Unit tests tell new developers what the system does and how it should do it but also provide a great safety net to a developer making changes for the first time in an existing codebase.
Finally, whatever code design approach you take, remain consistent to it but if you must deviate from the standard, document the reasons why.
Wrapping up
To summarise everything here, developing respectful software means having empathy for those who will interact with it in someway. Spend time thinking about how you can make things easier for these people. What you get back at the end is simply a better solution. It is a win-win right?
