I've been reading "The inmates are running the asylum" lately, and wow, is this book blowing my mind. I was amazed straight from the foreword, where the author states that the problems with the current software development process are due to accountancy, and then actually manages to explain it in a way that makes sense. I had never thought about the issues that way. The first chapter starts with examples of terrible software design in modern systems or appliances, and no matter your background you're forced to agree that this is all pretty crap. As a software developer I find myself often squirming in embarrassment at many of those failings, especially as some of them resonate so true to me (e.g. caring about the hierarchical file system when really, users would rather not have to worry about this ever...) This is a book I'm reading slowly to reflect on mistakes made, consider things under new perspectives, and hopefully do better next time.

I'm in a lucky position at my day job, in that in addition to my software development duties I get to interact with our stakeholders and customers. I love the opportunity to understand how my software is used and make it more useful, therefore I keep trying to improve the way I help refine requirements so that both parties end up happy. The book is helping me already by reshaping the way I go through that process. I was, and still am, guilty of figuring out what I'm supposed to do by making lists of features and of tasks to accomplish. Now I try to do this by thinking in terms of interactions, and what information would be helpful for the user to have on-screen. That I discovered Balsamiq's Mockups around the same time is lucky (and I shall write up a review of this awesome piece of software soon), as it's been helping me put together potential UI mockups in seconds instead of minutes -- drag and drop vs. somewhat realistic HTML.

Making and discussing quick mockups before writing the first line of code has been highlighting how, when design emerges only from coding, one is more likely to tweak things a bit to reduce/remove difficulties in the underlying code, and that's exactly the kind of small, mindless decisions that slowly take over a product until you end up with something that's not intuitive, sort of unpleasant to use and that would star brilliantly with all the terrible examples from Chapter 1 of the "inmates" book. It works but it's hard to use and makes the user feel stupid.

Unfortunately things are not just that simple. I've been trying to apply this new process, talking to my users and asking questions slanted toward understanding what sort of interaction they would find most useful and pleasant to use... but it takes a bit more to change a process. No matter what I ask, the answer tends to be, "whatever is fastest for you to build." There's probably a lot of factors mixed up in there. Needing the feature ASAP, dependence on the developers, self-knowledge that they are power users and can learn, awareness of the backlog size, wanting the dev freed up to work on the next feature/defect...

And they might not be wrong. In my fancy mockups from the last session, there are some elements that, now that I've started coding them in, I'm realising are not as simple as they look, and although of course it is possible to add them in, there will be a cost attached to it both in code complexity and time. I see the interaction cost of simply removing the feature ; I see the cost of keeping it in. This is going to be a balancing act rather than a process overhaul, especially since speed of development always matters so much. I still want to get better at making software that's enjoyable to use, though I can't let my productivity drop significantly to do that.

I'm enjoying a lot learning more about HCI. If  anyone has additional resources to recommend, please do share!