Sunday, March 31, 2013

The Human Side of (Agile) Software Development

In  the Sept/Oct 2012 issue of IEEE Software Linda Rising writes on the role of sterotype and collaboration in teams and explains that i t was only late in here career that she came to the realization that the "people side" of software development is both really important and really hard.

This is an important point, as it is quite easy to think that it's easy to ignore people in a project while you have more important things to work on, such as code, and tools. There is an intersection between people and tools; tools like Software Configuration Management systems, Wikis, issue tracking systems (be they software based or index cards on a wall) can improve or detract from the effectiveness of collaboration on your team. But it's easy to get hung up on the tools and not think about the effect of the tools on the really important thing: How the tools help (or hinder) the people on your team from collaborating to deliver business value.

I was fortunate to have had the importantance of the people side of software brought to my attention early in my career when one of my first managers suggested that I read The Psychology of Computer Programming. Over  time I  discovered more of  Jerry Weinberg's books, and all have had a had a great influence on me. A particular favorite of mine is Becoming a Technical Leader: An Organic Problem-Solving Approach.

It seems like, with resources like this around, and a focus on agile software development, it should be easier for developers to understand that people and teams are as important as they are. But acknowledgement of the humans side of software is not universal, even as we're starting to acknowledge parallels between software development and other endeavors such as artistic performance.

Fortunately there is a excellent recent book by Gil Broza, apltly named The Human Side of Agile, that explores the relationship between people, tools, and processes in software development. I posted a review on Techwell.com, but in brief,  this book is a great agile-focused addition to my list of recommended books on how help teams be effective. Reading this book early in your career will give you a good start on understanding an often neglected aspect of software development. Those who understand it already can benefit the guidance the book offers about how to help others understand.

Reading any (or all) of these books will help you understand how to be more effective, and how to help your team be more effective in turn.


Books mentioned in this post


Sunday, January 20, 2013

Usable Usability Across Virtual and Physical Spaces

Books on usability often focus on either software and web usability or usability in the physical world. In many cases services people use span the two. Physical objects often have a software component and many interactions span physical and virtual spaces. You need to consider usability not only in the context of the thing you are working on, but in the context of the system the person is interacting with. In other words, rather than thinking about the user experience for an application, it's worth thinking about the user experience for a service. Eric Reiss's book, Usable Usability: Simple Steps for Making Stuff Better provides you information to understand usability implications of web design, physical design, situations when the two intersect.

While any one book can't fully cover everything you need to know about usability across these spaces, Reiss does a great job job giving an overview of the issues, and pointers for more information Usable Usability: Simple Steps for Making Stuff Better reminds me of Donald Norman's Psychology of Everyday Things (newer editions being called The Design of Everyday Things).

The principles of good web design are not that different from good design of physical objects. There are many cases when a user experience spans the two; you may start a transaction online, ask for help on a phone call, and complete the transaction is a physical store.

This is a very readable, entertaining, book which weaves stories of his experiences with both bad and good usability, with actionable advice to help you understand both general principles of usability and specific guideline to employ when designing interfaces. The humorous stories of the effects of poor design will help you to remember what not to do, and the simplicity of the examples of good design will inspire you to aim higher in your projects. This book is especially worth a read if you are building
 software applications or services that have both a software and concrete component.