When you look deeper, it’s another example of extreme subtraction…

No cords. No buttons.

By loosing the excess, the mouse gains functionality and capability. All of the sudden, lots of new worlds and possibilities open up. We have the capability for multi-touch and a (mostly) unrestricted canvas for rich interaction because of the items that have been removed from the mouse.

Sound familiar?

This is the same design that opened up a new world of phones by removing the physical keyboard.

Thank you Apple

We develop software where 60+% of the functionality is never or rarely used. We focus on feature-matching the competition while we neglect listening to our users. We litter our presentations with excessive bullet points instead of focusing on our core message. We write user manuals that rival Atlas Shrugged because we’ve failed at providing usable interactions.

By nature, we tend to add when we should subtract. Evolution has plagued us with reactions that promote complexity and avoid clarity. When we create, we focus on building more – but when we consume, we tend to find the most joy out of having less.

How do we make a conscious effort to find simplicity in a world of complexity? Well, to start, we can start to think about thoughtful reduction.

Thoughtful reduction is an extremely powerful tool in our quest for simplicity.

The next time you are faced with an opportunity to improve or modify your process, or your software, or your life – think about what you can remove instead of what you can add. Take a little extra time to remove root causes instead of adding workarounds. Think about how to communicate more clearly instead of how to communicate more. Think about the things that you can stop doing instead of the things that you can start doing.

When we remove the non-essential then we end up with a stronger focus on the truly essential. Find the core of your application, your message, your purpose – and take away the rest. You might not end up winning the feature-race, but you could find a beautiful product and a renewed sense of focus.

You can also find the video on Vimeo.

The talk includes some discussion of testing, but it is mostly centered around figuring out how to deliver great software.

If you’re in the area, stop by and say hi.

I’ll post the presentation here after the talk.

The presentation is embedded below. If you download the presentation, it will have a summary of what was discussed in the presenter notes.

It’s interesting to me how much people rely on formal tools for modeling. I frequently talk to individuals that tend to assert that just because a model is made in some modeling tool (like Visio) that it is *right* or at least superior to whiteboard sketches.

The Visio fan-boys and fan-girls seem to snicker and generally doubt the effectiveness of a sketch done at a whiteboard. Why is this?

Is it because of the appearance? Is it the lack of gradients? Is it the lack of the drop shadows? Is it the lack of the standard company logo in the upper right-hand corner? Is it because of how straight the lines are?

My view is exactly the opposite. If I had to summarize my stance, I’d say that the straightness of the lines has an inverse effect on the understanding of the problem.

In my experience, most of the models created with modeling-tools are done by one individual. If others collaborate on the model, it’s usually in a serialized fashion. It’s “tossed over the wall” to someone else who follows a similar process. It’s also my experience that many people spend more time worrying about the polish of how the output looks than spending time thinking about what is being modeled.

Contrast this to a whiteboard-session:

When a model is explored on a whiteboard it’s usually done with more than one person. It’s usually done collaboratively with at least two participants, a variety of view-points, and it’s iterated on quickly. Because it’s being done collaboratively, it also frequently results in break-through ideas or understanding.

Unfortunately, the modeling tools also tend to focus our attention on the output, not the creation of the model (where the real learning occurs).

It’s important to remember that the modeling, learning, and understanding is what provides the real value, not the model.

Photo courtesy of Doc Searls.

In it’s basic structure, a user story follows the format of:

Most teams (at least in my experience), use the format:

An interesting assumption of this format is that we know what the feature that we will be implementing should be.

In many cases, this format neglects the tasks of taking some time and dedicating some effort to think about a suitable implementation. In some cases this might be ok (commoditized software, maintenance modifications, a thorough understanding of the solution space, et cetera). But, in cases where we are innovating or focusing on providing a differentiated user experience, this assumption can lead to a me-too product or mediocre software.

In the event that we need to think a bit about the solution, I’ve found it very useful to change the story format to be goal-oriented. My recommendation is to use a slightly different format:

This is a minor modification, but it certainly changes the focus.

The goal-oriented story format encourages empathy, understanding, and exploration. When we are in a situation where we are focused on delivering an optimal experience to our users, I think that the latter format is appropriate.

Don’t ask your users what to build. Instead, focus on understanding what your users “do.” Know the goals of your users, understand what they think, how they interact, what they do in their time-off, and understand what their life is like on a day-to-day basis. You can’t get this information by disconnected feedback, you have to get it face-to-face, side-by-side, through direct and unbiased observation.

Everyone who designs, develops, tests, and manages software products should be spending time with their users. Be an apprentice, observe your software in use in a natural environment, pay attention to the psychology and interactions – then you will understand what needs to be built.

Every interaction with a user in their natural environment will leave a lasting impact in how you understand your users and guide your product.

If you are having a hard time putting together compelling presentations then a great source of inspiration is to look to Wall Wood’s 22 Panels.

The 22 panels are great inspirations for help in designing your slides to tell the visual story of your content or ideas.

Do you work with people in India? Then go to India. Do you work with people in the China? Then go to China.

Making eye contact in a high-bandwidth environment can do wonders for teamwork and cohesion. In addition to the face-to-face time there is also the understanding and feeling of culture. Culture provides the basis for viewpoints and actions and without understanding the culture of your co-workers, how can you ever understand them as individuals?

As you make your budget for your project, always remember that your best tool for collaboration is a plane ticket.

Is there another alarm clock radio that’s more beautiful than this?

I stayed at a hotel recently that had one of these at the bedside. In a world full of horrible hotel alarm clocks, it was a welcome change.

Usability++

Nature is often neglected as a source of inspiration. There are many opportunities to look to nature to find solutions to our problems and inspiration for our thoughts.

Our minds and our thoughts are often shaped and blinded by growing up as children of industry. There was a world that existed before industrialization and there will likely be a world that exists after our impact is felt on this planet.

The next time that you look to any of the standard clichés that tend to rule our thinking – try looking to nature and see what you can come up with. My guess is that you will be surprised in what you find.

Video here.

If you haven’t seen the work of Chris Jordan, I highly recommend taking a little while to explore his work. Lightly put, it’s amazing.

Chris combines statistics and visualizations to produce a variety of thought-provoking, insightful, and beautiful visuals.

His most recent work can be seen in Running the Numbers – An American Self-Portrait.

I’d also recommend taking a few minutes to watch his talk from TED.

Something that I’ve noticed more and more lately is an increasing demand for “rules” in applying Agile development. Honestly, this has concerned me for the past couple of years. I always silently gritted my teeth and provided guidance backed up by a lot of “unless” clauses. I’ve usually taught from a “principles-based” approach and encouraged creativity around the principles.

Although I think that I’ve done a solid job in communicating the benefits and application of Agile methods and practices, I also feel like in many ways that I’ve left teams begging for prescriptions, rules, and best-practices. In my mind – those things have always been more problematic than helpful.

On the plane today, I started reading Pragmatic Thinking and Learning by Andy Hunt. By the second chapter, I had that OS!M (oh shit! moment) where a lot of things start to pull together in my mind. This all happened while reading through Andy’s explanation of the Dreyfus Learning Model. Suddenly, a lot of things started to make sense to me from a coaching standpoint.

The Dreyfus Model is a five-stage model that shows how individuals make the progression from Novice to Expert. The Dreyfus Model explains skill acquisition and the related ramifications of how we learn at different stages. This model was originally developed by a couple of brothers that were researching how we learn for some work they were doing around artificial intelligence.

An interesting insight from the Dreyfus Model is that at the Novice stage (the first stage), individuals need recipes. Novices are concerned about their ability to succeed and they don’t have any experience to draw from. Novices aren’t necessarily interested in learning, they simply want to accomplish an immediate goal. They are most effective when they are given the exact instruction of how to proceed. Take out context, take out the edge cases, take out the “it depends” scenarios and that’s what individuals that are new to a concept really care about.

When we move through the stages then context, the edge cases, and the “it depends” scenarios really start to matter and understanding the big picture plays a more relevant role in our learning. This explains a lot of what I have been trying to understand with the desire to have a “one size fits all” or “best-practices” approach to applying agility. In looking back at my own progression, I can see the exact characteristics that are defined in this model.

When I “prescribe” a practice or I provide exact steps for achieving an outcome then I feel like I’ve somehow cheated. This is because I know that there are not any universal truths in how we approach problems with software delivery and with agility. Maybe this feeling that I get should be re-evaluated. Maybe it’s ok to be prescriptive. Maybe it’s ok to provide recipes to new teams. At the very least, this is a great opportunity to re-think my assumptions and my world-view on how to be a great Agile Coach and to spend some time learning more about learning.

I’m looking forward to finishing the book and thinking through the information that Andy has provided in the book so far (I’m only through the first two chapters). It looks like it’s going to be another great release from the Pragmatic Bookshelf.

Here are the two definitions from the New Oxford American Dictionary…

The way I usually differentiate between these two terms and their accompanying mindsets can be partially described by thinking about taking a road-trip.

If I am trying to determine the best route to take to get from point A to point B then I have a variety of ways that I can reach my destination. When I choose which route to take – then I am thinking about effectiveness.

If I drive a specific route frequently then I can focus on efficiently navigating that specific route. If the road is paved then I probably want to drive my car (better gas mileage), if it’s a dirt road then I might need drive my SUV. When I apply the context of my route – then I am thinking about efficiency.

The differences in these definitions is slight, but important. When I focus on effectiveness then I’m looking at ways I can achieve a specific goal. When I’m looking at efficiency then I’m looking at optimizing the way I’ve chosen to achieve the goal.

If you think about the subtle differences between these two mindsets then it’s fairly obvious that software development almost always focuses on efficiency. Unfortunately, there are many times that we focus on optimizing our gas mileage while we are taking the wrong route to get to our destination.

When you need to focusing on doing the right thing then focus on effectiveness. When you need to focus on optimizing the right thing then focus on efficiency.

If you’re in a situation where things change frequently then effectiveness should be your focus. After you solve the effectiveness problems then you can focus on efficiency.

How old were you when you started programming?
I wrote a few games (when you had to type in the games) on the TRS-80 when I was in elementary school. I think I wrote two or three of those games as a kid. I really didn’t start programming though until I was in college. I think I was 20 when I took my first programming class.

How did you get started in programming?
I took an internship to be a network engineer. I was lucky and got the internship, but there weren’t any projects for me to do. One day, the company I was working for asked me if I’d like to go hang out with the developers and see if I could help out. Fortunately, the developers were great mentors and they taught me how to write code. When a real networking position came up I declined it and kept hanging out with those same developers.

What was your first language?
Those TRS-80 games I wrote were in basic. The code I wrote in college was mostly VB.

What was the first real program you wrote?
I wrote an application for a law firm to track their hours for billing clients. Apparently, they had a hard time finding a time-tracking and billing application that would let each of the lawyers bill over 24 hours a day.

What was your first professional programming gig?
Doing (the hell that was) Windows DNA for a consulting firm while I was still in college.

If you know what you know now, would you have started programming?
Absolutely.

If there is one thing you learned along the way that you would tell new developers, what would it be?
Focus on the quality of the people that you work with and use it as a guide to find the right job. Your best bet for progressing in the field is to work with people that are better than you and have the ability and the desire to mentor others.

What’s the most fun you’ve ever had … programming?
My first agile project. XP by the book. I was very close to burning out and it re-ignited my passion for writing code and building valuable software. There were a ton of new things to learn and many things to re-think.

I have a handful of things that I would like to change (mostly related to usability) and some code that I want to clean up before I put out a version 1.0 drop and I’ll probably get around to this sooner than later.

The one additional thing that I’d like to see are some requests for different types of visualizations that can be built into the tool. The current visualizations (there’s only two) are very simple and they seem to work very well. While these two visualizations are nice and simple, I’d like to put a few extra skins in place before doing the 1.0 drop.

If you’ve got any ideas or have any inspiration for what can/should be done, please head over to the GetSatisfaction site and put your ideas on the thread that was just started.

Currently, the two views are LiveStackedStatus and LiveUniformStatus (these will be given friendly names before the release). Here are the two views…

LiveUniformStatus

LiveStackedStatus

Both of these views are only relevant if you have multiple projects being hosted by your cruise instance. If you only have a single instance hosted, then you’ll only see one large box with your project status. The best view typically depends on the number of projects that you have available. If you have more than four projects hosted then LiveUniformStatus tends to give you the best view and four or fewer projects tends to look best with the LiveStackedStatus.

If you have non-visualization requests, you can also feel free to post them and I’ll take them into consideration as well.

If you’re anywhere near Raleigh on May 6th, be sure to check out the Agile RTP meeting. We’ve got Andy Hunt coming to talk and I’m sure it’s going to be worth your time to attend. The title of the talk is Refactoring Your Wetware.

If I could point to two or three people that have shaped my thoughts about programming and development, Andy would be at the top of that list.

If I could only recommend one book to anyone doing development, it would be The Pragmatic Programmer. The book certainly changed the way that I think and has certainly shaped my career. Interestingly, it’s the only (at least partially) technical book that made my list of books that changed my life.

If you’re in the area (or if you feel like taking a road trip), be sure to come by and see Andy talk and participate in the discussion at Agile RTP.

If you don’t get it (I didn’t at first either), check out this great video that I just ran across from Common Craft … on Vimeo…

Twitter in Plain English from leelefever on Vimeo.

#1) First and foremost, I’m a dad

Whitney and I had our first child (Haley Kay Carey) on January 30th. Everyone is doing wonderful and I’m loving being a dad. Right now, this is where the majority of my focus has been channeled. Haley is doing awesome, Whitney is doing awesome, and I’m doing awesome.

You can find our pictures of Haley on Flickr at: http://flickr.com/photos/thecareyfam/tags/haley/

#2) If you’re interested in what I’m doing (until I get back to blogging more), I’m using Twitter frequently. It’s much easier to do the micro-blog thing with Twitter.

You can find my Twitter profile at: http://twitter.com//bencarey

#3) I created a small web page to hold the links to my small projects and experiments. There’s not much on the site right now, but there will be as time moves on. I have a lot of little experiments that I’d like to try and this will probably be where I link them up (I’m sure I’ll blog about them as well).

The new site is: http://www.hellokensho.com

#4) I launched Omakase. This was a little idea to experiment with Rails, iPhone development, and some ideas for exploring ways to make micro-applications. Omakase does one thing… it makes decisions for you. I’ll post more about it after I finish cleaning it up a bit. The site was written for the iPhone, but it does have a traditional browser version as well. Currently, the browser site looks the best in Safari.

You can find Omakase at: http://www.iloveomakase.com

#5) I moved my blog and site host over to Media Temple. As part of that move, I wiped out all of the categories for my old blog entries. I did this on purpose. I do blog about a mixture of items (technology, business, development, life, travel, etc.) and I decided that all of the categories just weren’t worth the effort to maintain them.

I’ll get back to blogging, speaking, and the various communities before too much longer. For now, I’m enjoying a bit of a break and soaking up the new addition to the family.

“Consider this: All ants on the planet, taken together, have a biomass greater than that of humans. Ants have been incredibly industrious for millions of years. Yet their productiveness nourishes plants, animals, and soil. Human industry has been in full swing for little over a century, yet it has brought about a decline in almost every ecosystem on the planet. Nature doesn’t have a design problem. People do.”

- Cradle To Cradle

I just returned from the Seed Conference and all I can say is wow. This was a wonderful, thought-provoking, and inspirational event. If another one comes up, I highly recommend attending.

There was a lot of interesting information that was presented both directly and in-between the lines of the talks. It’s great to see so many inspiring individuals giving talks and hanging out at the conference. There were a ton of fresh ideas and a strong sense of innovation that was felt throughout the day.

Carlos Segura, Jason Fried, Edward Lifson, and Jim Coudal all gave great talks with good content.

If I had to boil it down to a few over-arching themes – the conference was really about truth, happiness, pride, innovation, and getting real.

I also can’t say enough about the location of the event. As someone who sits in a typical office environment most of the week, it was refreshing to be in an environment that encourages learning and has inspiration at every turn. It was also nice to be surrounded by individuals that are pushing the boundaries of our industry and unsatisfied with the status quo.

Over the next week or so, I’ll try to get around to posting some of the notes that I have from the event (1/2 a Moleskine full).