…a little bit at a time.

So yesterday at TWU we had a session called Analysis in Context, which was (for me at least) exactly what I have been looking for in terms of lessons that I can wholeheartedly agree with. During the session, the “dirty secret of software development” was revealed to us. I’ll release the dirty secret for the whole wide interweb to hear:

Software Development might not be about software at all.

Can you believe it? I certainly can. Now, this is in no way meant to put down all those people who spend many of their waking hours writing code. I just mean to underscore the fact that software users don’t want or need to use software just for the sake of getting code to work…they just want to do their thing. People want help working on the things that they enjoy working on, which may or may not have anything to do with a computer.

Writing good software requires good research. One really has to figure out the nature of the problem at hand. It’s not about what the client or user wants, it’s about what they do.

So we’ve started delving a little deeper into Agile Development today at TWU. Today we discussed the balance of quality and timebound delivery, as well as iterative software development and adaptive planning. Below I’d like to discuss an issue that is near and dear to my heart, an issue that really worries me about Agile methods, or really any kind of development that advocates the writing of code at an early stage.

In an Agile project, it is likely that a development team begins to write computer code nearly immediately when starting a project, or at least that’s my perception. By immediately, I mean to say that code is created within the first week of the project, if not the first or second day. Meanwhile, a team of Analysts goes and studies the work processes to help the customer figure out exactly what kind of software will be needed. I’m going to assume that at an early stage of a project, the development team makes some assumptions about what will be needed, and commits some ideas to code before they are sure that it will be needed.

This, for me, is where the problem begins. Whenever computer code is created for its own sake, or without proper research, there is potential for the developer to become married to their code. Here’s a scenario:

The team comes to a work site and meets with the client, who has asked that an internal system be created that helps employees communicate with each other, despite the fact that they are distributed around the world. One of the developers immediately thinks of a *great* feature: real-time chat. In the next few hours, he creates a web-based chat tool that can easily be plugged in to a system. He is really excited. This is something he has wanted to try to do for a long time, and finally has had the opportunity to do.

Meanwhile, one of the analysts has been chatting with some of the employees and realizes that all of the collocated employees in each office have no problem keeping in contact with each other simply through face to face communication. The problem, however, is that employees who work in different locations also work in different time zones, and are rarely ever working at the same time. Logically, this means that real-time chat is not a feature that will improve the communication system.

Now we have a real problem. Our developer has fallen in love with an idea, has created it, and will likely be reluctant to let it go. The analyst has evidence that the feature is not needed, and requests that the tool be removed. Now what? Is it an interpersonal problem? Will the developer take this personally? What about his precious time that was spent creating the tool?

Since the feature was created before the development and analysis teams really understood the nature of the design question at hand, it ran the risk of being unneeded. In this case, the tool turned out to be unneeded. The developer may take this event as a war story about “that time the analyst stole the glory and made him remove the best feature.”

But what about the users? The users don’t need it…so why code it? This is just one of the things that bugs me about Agile…code is created so early. Maybe I’m exaggerating the story a bit, but still, nobody likes to throw out work, right?

Maybe some of you agile experts out there can shine some light on the subject and help your soon-to-be peer clear some things up…

Summary: When studying user experience, the brain and its activities need not be considered in terms of separate function.

For the past few days, I’ve been taking in the following image, linked to me from the blog of a future coworker of mine, which was originally linked from here.

In science today, many people spend their careers dissecting, disseminating, breaking apart, and then explaining phenomena, anatomies, and actions. This is all well and good. The people who do this work should be honored, because they carry out an important task in quantifying the many qualities of the world. This leads to understanding of complex processes, which leads to many important things like medicines, technologies, and the philosophical underpinnings that explain to us as humans how the world works.

It is all to often, though, that those in non-scientific field appropriate quantitative data into realms of the world in which it should not necessarily be subjected. Sure, researchers in the neurosciences separated the brain into gross approximations many, many years ago. The most basic separation is the left-brain, right-brain split, which in popular media today symbolizes two different types of people in our society. Lesser known are the brain’s quadrants, roughly depicted in the above image alternatively as (clockwise, from left) Occipital, Parietal, Frontal, and Temporal. (There’s also the cerebellum, which is that big, bulbous thing that hangs at the bottom, but it’s often ignored in brain area discussions…not sure why.)

Denoting these basic brain areas was (and is) important for neuroscientists. It helps to create a basic map of the brain, so that we can generalize theories, then dig deeper to understand them. What worries me, however, is when these brain areas are engendered with specific emotions, or otherwise obfuscating labels. In fact, ‘curious’ thought patterns are not located in the Occipital lobe, but this graphic seems to say that they are. The same is true of the other thought patterns and brain areas noted in the graphic.

To take this issue a little further, I do not believe that it is fair to boil down the user experience to these four basic notions of emotion. The user’s experience is a holistic one, that cannot be broken down and “tweaked.” It is not possible to “add a dash of analytics,” or “take away a little curiosity.” When a designer changes one aspect of an experience, he or she automatically and implicitly changes many others.

Still, the notions expressed in the fine text of this graphic are important to understand and consider. So how is this issue reconciled? I do see some validity in assigning a brain area and specific color for each of the pieces of the “Creative Mind” as explained in the image above. Doing this helps the viewer remember each topic, because it is assigned to an area on a visual map.

It is important that we simply not take these lines too seriously, and realize that our understanding of the brain and human experience are blurry things. There are no distinct lines, and notions of experience bleed together constantly. We must be careful with our graphic illustrations, because we may be crafting explanations that are true in one sense, but false in so many others.

“There are rules in graphic design, Tiffanie…It’s not ‘nam.”

- Erik to Tif, after asking for advice on her capstone poster

The obnoxious behavior and obscure interaction that software-based products exhibit is institutionalizing what I call “software apartheid,” where otherwise normal people are fobidden from entering the job market and participating in society because they cannot use computers effectively. In our enlightened society, social activists are working hard to break down race and class barriers while technologists are hard at work inadvertently erecting new, bigger ones. By purposefully designing our software-based products to be more human and forgiving, we can automatically make them more inclusive, more class- and color-blind.

Alan Cooper, The Inmates are Running the Asylum

I think that’s where my friends and I come in…

Is this a Sci-Fi horror story? Nope, it doesn’t look like it. In fact, congress is voting next week on the issue of Net Neutrality which, despite its difficult to decipher name, is a vital issue to everyone who uses the internet today. Here’s the deal: AT&T and other big telephone companies who transfer internet data over their lines want a piece of the pie that makes big tech companies like Google, Yahoo, and other companies rich. The tech companies basically use the data lines for “free,” while network users pay for a connection.

The way the Telecom companies want to fix this problem is by ending this Net Neutrality and charging people who want to post things on the internet a fee in to not slow down the speed at which data is sent to the page’s customer. This is dangerous, though, because it will mean the the Telecom companies will be able to pick and choose their own “favorite” tech companies, and charge them variable rates. They may even charge the little guys who just want to build a startup from scratch.

Click on the link above to find out how you can help. Start by signing the petition to help save the internet, then call your congressman.

Had a wonderful ride into work this morning. It’s a 2.5 mile ride from home to office, probably 2 miles of that is pretty flat, but right at the start there’s a huge huge huge hill that just kills every time. Tuesday I made it a little more than 2/3 of the way up before I absolutely had to get off and walk. I remember looking out at this sign post thinking to myself, “Ok Josh, just make it to that sign, then you can walk.” Miraculously, today I was able to make it to that sign without even noticing, and rode nearly the entire hill. At the end I started dying (probably because I ate breakfast right before walking out the door), so I walked again and rode the next 2 miles into work.

Yesterday at the climbing gym I was actually able to do some climbing. Everything before yesterday was basically just a warmup routine. I’d get on an easy traverse path, pick some relatively simple problems, and climb until my body was sore. Yesterday, however, I was actually able to climb around until I was sweaty and tired overall, because my body is now able to support me.

I love getting in shape, if for no other reason than the fact that I get to witness my body adapting to change. I see my muscles adapt to the demands and stress, and I can actually feel the plasticity in my brain. That’s right, I can intuitively notice how the neurons in my brain are talking to each other in new ways, and know that new neurons are being generated to support the old ones so I can learn become a more adept athlete. I love the feeling of learning, especially when the learning is in the form of tacit knowledge, the kind where I don’t have to worry about learning the stuff. I just have to keep doing it and my body will eventually take over. Next time you take on a new task check up on yourself every week or so, and realize that your body is changing in ways you’d never normally think about.

A little over a month ago my body was primed to run a marathon. I am simply amazed that in so little time it can begin to change its form from runner to climber to cyclist and back again.