In my previous post I outlined my ideas on the concept of humanity as a key factor in the success of a software team. In this post I’d like to point out a couple of examples of what can happen to a product when humanity is absent from a project – one from a user’s perspective and one from a development team’s perspective.
Exhibit A: The user interface from Hell
The first example comes from an HR portal belonging to a nationwide company with thousands of employees. In this portal there is a place where users can search for and download pay stubs:
Now keep in mind that the user is already logged in to the system at this time. Yet they are still prompted to enter their Social Security number and date of birth. This is idiotic. The user is authenticated, and the system knows who it is, yet it still asks the user to authenticate – this time in a different way from the username/password he used to initially log in.
OK, I’m willing to accept that there may be some valid security reasoning behind this extra layer of security, and that Really Smart People dream up things like this. Even so I think it’s a horrible and unnecessary user experience. But besides that, there is another spectacular failure on this page. Next to the Date of Birth text box, there is a little Date-Picker-thingy. When you click on it to pick a date, you get this….
Now, finally, the user is able to select his birth year, and continue on with his task – if he can even remember what that task was to begin with.
Clearly this is a broken interface! But wait, what does this have to do with humanity?
Well, here’s the kicker….
This user interface completely satisfied the Business Requirement for this functionality. It passed User Acceptance Testing with flying colors! It was rolled out to production, and no one had any clue(or if someone did, he didn’t care enough to speak up) how truly godawful this screen really was.
Things like this only happen when the team engaged in the work has no real human connection to the business being served, and doesn’t have any notion that the system they are building will be used by actual human people who will curse and bemoan its failures for years to come. To them, it’s just a series of technical specifications on an office document, no more, no less. But it doesn’t have to be this way.
Exhibit B: The project team only an accountant could love.
The second example has no screen shots or user experience anecdotes. It could be an actual project team but the reality is I’ve seen this example played out a number of times in my career. It goes something like this.
The development team is housed in one part of the country. The business is several hundred miles away. The testers are on another continent on the other side of the world. The infrastructure team is on another continent still. At no time are all of the team members observing regular business hours at the same time.
How is this a problem? After all, with technology we are always connected, right? Well, consider this: when testers are blocked by broken functionality or misunderstood implementation they often must wait until the next day to get a resolution. When developers have misunderstandings about requirements, they must hash it out over the phone, which is a sub-optimal format for conveying complex issues and subtle concepts. When the business users see functionality that has been implemented according to the written spec but the written spec was deficient or vague, time is lost, money is wasted, or the business must resign to accept less.
Software is a complex technical undertaking, but if you approach it as a merely technical endeavor you are missing half the point. Software is also very much a social product, as well, and it is a one-off product. You cannot create software like you manufacture a car, using interchangeable parts, interchangeable laborers and process. You cannot mass-produce innovation.
There is a better way, and I have seen it. I’ll talk about my ideas on creating a better software team in part 3 of this post.