Way too many sleeps ago, Russ Ackoff shared that the best information retrieval system and best knowledge transfer system was the collection of graduate students that worked with him at Penn’s Wharton School. “Every morning when I come into the office there will be 2-3 articles taped to my door that somebody thinks is important for my research. They are always spot on” Russ shared.
Last Saturday evening a Tweet arrived from two UW HCDE grad students (Drew Paine and Behzod Sirjani) asking if they could come over on Sunday afternoon and enjoy the view of Puget Sound from our deck on Bainbridge Island. “Of course, we’ll bring the food. All you have to do is supply the wine.”
“Done,” I replied.
Drew is in the process of starting his PhD research on the topic of human centered software development. In all of my focus on using human centered design (HCD) and teaching HCD, I don’t remember ever putting human centered with software development before. I asked Drew what he meant by the phrase.
Drew shared that he was interested in how non-software engineers, like scientists, develop software to support their research. They are self-taught and often use scripting language as a way of making sense of their data. They are able to get important things done, but are doing it without formal knowledge. So he wants to understand how to make computational thinking and computational doing more approachable to all of those professionals who aren’t going to go through a computer science or software engineering curriculum.
Human centered software development conjures up something very different for me. I believed the phrase should mean getting software developers to move from being technology centric to being human centric. I have the hardest time getting software engineers to pay attention to what a user really needs rather than focusing on the minutia of getting a program to actually work. Or worse, the software developer focuses on what would be neat to build.
So I looked to Behzod to share what he thought human centered software development might mean. As he sipped some of the Dominio IV wine, I’d pulled up from our spiral wine cellar, Behzod expressed his belief that it meant we need better tools for crafting software programs. He goes crazy with the arcane languages that we have to express a program to the computer and thinks that something like Scratch should be the way we all develop programs. “It is not just the language itself that needs to be more human centered, but also the system and the way that software developers can collaborate. That’s what I like with Scratch. And the real problem is that no program contains the knowledge necessary for someone else to pick up and modify the program. That is the area that we need software to be more human centered.”
As you can imagine, with good wine and a great view an enlightening conversation ensued.
The next evening, Bill Knight, dropped by to listen to some of my “rubber meets the sky” ideas about the next tool I want to build and to share some fine wine. Bill has been kind enough to listen to my flights of fancy since we worked together at Aldus back in 1990. Since Bill is an incredibly accomplished software engineer and CTO, I asked him what he thinks human centered software development means.
Bill shared that he thinks the term means embedding software developers onsite with the humans who have the problem that is trying to be solved for. “Most of the time, software developers are many hours or time zones removed from the people that they are developing solutions for. The term means to me that you should embed the developers directly with the key users in the problem space. Human centered software development is problem space focused. It’s what we did at Attenex by embedding ourselves with the Preston Gates eDiscovery lawyers.”
As we continued the discussion, Bill added that by embedding software developers one should shift to focusing on the process and make the process more understandable. “We have to make the software relevant and the only way to do that is by embedding the developers deeply into the problem space.”
With four interesting view points on what human centered software engineering might mean, I can’t wait for Drew to get started with his PhD research and see where he ends up.
And just to have some fun, I decided to see if Google had any images on the subject. Up came an old IBM diagram:
So what do you think human centered software development means?
On the Way to Somewhere Else 
I should probably add in that I am interested in not only scientists and other professionals who develop software to support their larger work practices but also those persons who consider themselves to be software engineers/developers and what being human-centered looks like for all sides.
It’s a known problem of designing development environment to be as simple and easy as possible to make the required tasks done without obtaining a necessary large body of knowledge.
There are different practical approaches towards solutions of this problem, from the mid-50s up until now. We’ve researched this topic a while ago and found few different solutions (that are more or less successful in achieving the goal).
First, there is Microsoft’s SmallBasic that is kind of success. Second, there’s Microsoft’s (again!) Kodu which seems to be also focused on visual language. The third thing is IMPURE (http://www.impure.com/), which is a bit interesting and worth looking onto:
“Impure is a visual programming language aimed to gather, process and visualize information. With impure is possible to obtain information from very different sources; from user owned data to diverse feeds in internet, including social media data, real time or historical financial information, images, news, search queries and many more. Impure is a tool to be in touch with data around internet, to deeply understand it. Within a modular logic interface you can quickly link information to operators, controls and visualization methods, bringing all the power of the comprehension of information and knowledge to the not programmers that want to work with information in a professional way”.
A pretty old approach I recall is Yahoo! Pipes which is somewhat similar to IMPURE, but much simpler and as such less powerful.
To sum up, the point is that there is the old good balance between the more complicated interface that provides a bigger power, and a much simpler interface that is fast to learn but it may lack some of the powerful features (say operations you can make on data). In case of a simple tool you need to invent the rest with your mind which might take more time but you’ll eventually get more out of the process, while in the second case you’ll be more limited to things you learned by using specific and more powerful system; its power will turn into your weakness.
..
I agree to some degree that putting developers into much stronger collaboration with end users might make more sense, but unless software is designed for very specific set of users, specifics of these people (and they’ll be a very small selection of people anyway) might prevent developers to see the forest behind the trees. A well-known approach Donald Norman once proposed to use in that case is “personas” where typical user profiles are built; guess Drew knows that anyway so it’d be interesting to hear his point of view on this topic.
…
a few more thoughts. Programming is not something entirely different from all other human activities, it is a natural thing for people who are living in programming world everyday; so new things become natural when you are get used to something very similar to these new things, right? Thus, to design a system that will help to develop new software in a natural way, it might make sense to use metaphors/language dialect used in that specific science area these “non-developers” are from.
These metaphors can be based on different interactions that are common for these “non-developers” – air gestures, specific language acts, touch gestures, etc. I mean, for the scientist who’s working on classic mechanics (physics) her language used to explain things, say, gestures or models, these all things make a lot of sense; they can be turned into input to program the system. Just a crazy idea but I feel there’s eventually something in it.
…
In total, I guess it’s a good thing to enjoy a taste of nice wine together with great landscapes of Puget Sound 🙂
Anyway, the idea of human centered software development is interesting and worth working on.
Pingback: Epistemology of Software? | On the Way to Somewhere Else
Pingback: Feeling Thankfully Reflective | On the Way to Somewhere Else