Distance Release Date and nearly a month time, cheap jordans decided it was time nike lebron 10 for the launch of the engraved version of the retro jordans invasion sneakers fans wallet.

In Theory: Stakeholder Interviews

Let me preface this by saying, as stated in the title, that this is theory. This is what I plan to do when I have the opportunity to interview stakeholders, and the value I expect it will provide. But, I haven’t had the opportunity to do any interviews just yet.

Like I mentioned in my previous post, one of the first tasks in user experience design is to concretely understand the goals of the project stakeholders, possibly helping them flesh out thoughts and abstract ideas in the process. Stakeholder interviews, as described by Shawn Crowley at Atomic Object, are intended to help bring those thoughts to the surface and, through discussion, document a set of goals and motivations. The system he described involves a pair of interviewers and a single stakeholder interviewee: one interviewer guides the discussion using a mix of open- and closed-ended questions while the other takes notes.

The questions should try to draw out not only qualitative descriptions of goals, but also quantitative when possible (e.g., Market saturation percentage targets, net income). Some questions we discussed include:

  • What is success? Failure?
  • Who are you doing this for?
  • What are your constraints (time, money, etc.)?
  • What is your vision for this product?
  • Tell me the future

For the note taker, a set of 3×5 cards should work well for documenting statements the stakeholder makes. The notes must be factual, not the note taker’s opinion. After the interview, both of the interviewers should review the set of notes to make sure they are factual — grounded in reality. Any statements that are tainted by interviewer opinion should be discarded or distilled down to the factual information. After the interview, review the notes with the stakeholder using whatever method you deem appropriate (I’ll probably send a follow-up e-mail, since I tend to do that after meetings anyway). If you must make assumptions, be absolutely sure you check those assumptions with the necessary stakeholders or you risk driving the project off course from the very beginning.

Now that you have one set of information, repeat the process with others involved in the project. Stakeholders can take a variety of roles, so be sure that variety is reflected in your pool of people to interview. Previous interviews are likely to identify new people who should be interviewed. I’ll be likely to include people from business leadership, marketing, and other subject matter experts in my interviews to be sure we are getting the whole picture and describing goals clearly.

As Shawn and I discussed, the value of these interviews lies in the focus on fact. We can use the information we gather to reflect the business goals, metrics, and target audience back to the stakeholders as a framework for discussion. This becomes a single point to align the stakeholders, developers, designers, and others involved in the project toward the same set of goals and will be a valuable tool to guide decisions down the road.

In theory, that is. We’ll see how it goes.

Diving into UX

I love a challenge, and the diversity of the challenges I face on a regular basis is one reason I really enjoy my work. My latest challenge has had less to do with writing code and more to do with taking ideas from conception, through research and evaluation, to a basic project plan. I’ve been involved in the early stages of concept development before, but never with this many ideas at once or with this much stake in the outcome. So, I’m taking this opportunity to learn and hopefully improve our process along the way by diving into user experience design.

There is an awful lot of documentation on the internet about user experience design. I’ve read through a bit of it, and through reading I came to understand the basic gist of things like stories, personas, and wireframes. Until yesterday, though, I still felt like I wasn’t getting the big picture — how do all of these things fit together and eventually lead to an informed project plan? Thanks to a great Thursday afternoon discussion with Shawn Crowley over at Atomic Object, I’m starting to see how I can apply the process of UX design to my project. Instead of sharing particular methods first, I’d like to talk about general application of the process to my project and how I envision it will provide value for me, my fellow developers and designers, and the project stakeholders.

Shawn did a really great job of walking me through the process Atomic Object is employing in user experience design, and that has helped form in my mind an idea of what the process is intended to achieve — the big picture that was missing from online materials. Apart from any concrete deliverables, their aim is to:

  1. Identify stakeholder goals & motivations
  2. Identify & understand target audiences
  3. Identify activities involved in achieving stakeholder & user goals
  4. Assemble a high-level release plan for estimation & evaluation
  5. Add detail to tasks for the first release to support development planning
  6. Execute development & other design activities to implement release plan

Concrete deliverables from the process will relate to one or more of the abstract goals above. Each step builds on the previous, introducing new information and keeping the process grounded in facts.

I’m going to start at step one by asking myself a simple question, “How do I identify stakeholder goals and motivations?” One of the methods Shawn and I talked about was a pair interview with a stakeholder: one person asks questions while the other person writes down facts to be reviewed later. But, I already have answers to a lot of the questions I’d ask and I don’t want to waste someone’s time asking them questions I already know the answers to. Instead, I’ll probably start by writing down facts I already know and review them with the stakeholder in a brief conversation. Not that I wouldn’t like to interview them, but it wouldn’t add a lot of value for either of us at this point. I’ll tackle each goal in a similar way, identifying methods and deliverables that have value to me and to my stakeholders, up to the point where I’ve achieved my goal of providing an actionable, loosely estimated release plan.

The process of user experience design is not one for robots. The decision to include or exclude specific techniques or artifacts is entirely up to you, and should be based on the value that they will provide you, your stakeholders, or others involved in your process. Ask yourself and your stakeholders how a particular method or deliverable helps you achieve your goals before blindly writing a detailed process flow or creating a wonderful functioning prototype. For me and my stakeholders, things like high-level stories, reasonable personas derived from past user labs, wireframes (rough, sketchy mockups), and context scenarios are going to be of primary importance because they are useful in communicating our vision. Other artifacts, like content inventories and prototypes, aren’t as valuable to us at this point because we’re still trying to determine the value of our ideas.

At each step I’ll be using the results of the previous steps to inform decisions about prioritization, keep product features and functions on target, and squash disagreements not based on facts.  I’m really eager to see where this leads because it appears it will help answer questions I’ve been asking myself and my teammates about communicating project ideas and keeping a cohesive vision across functional teams.

Again, I have to thank Shawn Crowley and Atomic Object for giving me the opportunity to learn from their experience. I’m looking forward to continued conversations as I begin to put user experience design principles into practice, and I’ll do my best to keep sharing what I learn.

Going to make some noise

It’s been awfully quiet on this front lately, but that doesn’t mean I’ve been idle.  On the contrary, I’ve got some interesting things coming up and I’m going to try, really try, to do better at sharing what I’ve been working on and learning about.  What can you expect?  How about a few examples:

  • Drawing graphs with Perl & Cairo (notes from GRPM meeting months ago… sorry for the delay)
  • Fun with mad libs in Perl
  • Discussion on testing with Perl — Test::MockObject in particular
  • System testing with Selenium & Perl
  • BarCamp Grand Rapids, GRPM, and other user groups
  • And plenty more Perl!
Sometimes it just takes a swift kick to spur things along.  If you need a kick yourself, and you happen to be a Perl guy or gal, Matt S. Trout has got one for you (mind the profanity).

Perl: Old and crufty?

I hear people mummbling a lot about whether or not Perl is dying, but I think a better question is, “Is Perl perceived as old and crufty?”.  I think the answer is related to the perception that Perl is dying and I think there may be something the Perl community can do about it.

First, let me define what I mean by the phrase old and crufty.  When was the last time you cleaned out a communal refridgerator at work, church, or even at home?  What did you find?  Chances are you threw out anything that was obviously bad or wasn’t in a reusable container, but what about the questionable items?  You left them in there because they might belong to someone else, and they might still use them.  Even if you wouldn’t, they might.  So they didn’t get cleaned up.  That is what I call cruft.

Software developers don’t like cruft.  In our own code, we have the ability to see what is used and unused and clean vigorously.  It feels good to finish a rewrite or update to a system knowing that everything is nice and tight —  shiny code.  Or at least my perfectionist tendencies make me feel that way.  So, when I see comments like this on the Perl 5 Porters mailing list, it makes me cringe:

But I’d be scared of making it in any stable release as I would be surprise if someone somewhere isn’t matching on it, and ignoring the current term.

The change being discussed isn’t necessarily even one I would be in favor of, but it is a classic example of the kind of talk that leads into the perception of a language being full of cruft that developers don’t like.  I can understand how, through reading this type of comment, a person could come to see Perl as a language that is dying, not advancing, because the community is too afraid to make changes that would improve the language.

Now for some positivity: I think this perception can be changed, partly through the addition of quantitative analysis.  For example, if we take CPAN to be a (non-random, obviously) sample of all Perl code, then we can check to see if any module on CPAN checks the actual value of a warning someone requested a change to.  There are other Perl-based open source projects that can be grepped (or Ack-ed) through to quantify the potential impact of a change.  Instead of stating, “someone, somewhere might use <blather> for <unintended_use>”, try to add to it, “… but there were no modules on CPAN that did, and neither do open sourc projects A, B, and C.”  Perhaps we could even put together a set of projects and a tool to check outside of CPAN to make it easier to judge the impact of a proposed change.

Thoughts, anyone?

FUD as Technical Debt

Fear, uncertainty, and doubt almost surely lead to technical debt when they are left to fester in the software development process. Chances are good that you’ve seen the symptoms of FUD in your own code at some point, or at least in someone else’s. The following are a few examples I’ve run across recently, coupled with hopefully useful suggestions on how to keep FUD and its associated debt out of your software.

Unused

It is all too common to find unused variables, subroutines, or unnecessary libraries included in a program. Often they are remnants of a shoddy refactoring effort, or the result of a developer who is outside their comfort zone with the language and tools being used. This excess code can confuse unwary maintainers or, in the worst cases, cause errant behavior in the software. Clean up anything that is not necessary in your own code, and encourage others to do the same. If you are unsure whether removing a variable or library will break your code, test your suspicion instead of letting your uncertainty remain. 

Duplication & Stagnation

When confronting someone with a refactoring need, how often have you heard the excuse, “But I’m afraid I’ll break something.”? The fear of refactoring can lead to duplication of code, lingering problems, and general stagnation of the code base. As Andy Lester mentions in his technical debt presentations, even the feeling that code is broken affects how we deal with it (the broken window effect). We hopefully learn more about our craft every day, and refactoring is a valuable way to apply new knowledge and best practices to our work. 

Probably the best way to give confidence in refactoring is to have a solid suite of tests covering the affected code. It is very reassuring to see tests pass before and after large changes. Spending time to develop a deeper understanding of a program’s function also lends a degree of confidence — I suggest spending that time writing or improving the test suite.

Why does it work?

As software developers, we ought to be able to explain how and why our software functions, not just declare that it passes the tests. A lack of understanding can lead to unexpected behavior in untested situations and nightmares for anyone left to maintain the code. If the person who wrote it can’t explain how it works, what hope does anyone else have?

Pair programming requires talking through code as it is written, and that helps understanding a lot. If you find yourself alone, talk it through yourself or find someone to explain it to later (as part of a code review process, perhaps). Ask questions of your fellow developers when you don’t understand what they’ve written, and be prepared to question your assumptions when things don’t work how you thought they should.