"If the person responsible for using the system does not benefit, the system is doomed to failure." - Grudin's Law, Jonathan Grudin

We need to recognize that pushing our pain, that is, our needs, on someone else to implement will at best give us grudging and resentful compliance. If we can ensure that the person receiving the benefit is the one doing the work, we will get a more motivated group of performers.For example, the marketing group for a retailer decides they want zip codes from all of their customers. It involves more work for the cashier, and is resisted by customers. If there is no clear incentive for the cashier, or consequences of failure, the cashiers will enter false data in an attempt to make their lives easier.What we need to do in cases like this is to show the clear benefits of the task to the user and get them "on our side". The other option is to monitor and correct issues, but the carrot is preferable to the stick.

"Designs fail when the effort required is greater than the time available at the moment of need or the perceived benefit." - Gery's Law, Gloria Gery

effort required > (time available + perceived benefit) = system failure

Since in most cases we cannot increase the time available (we only wish we could), we must either

1) reduce the effort required (make the system more intuitive, fewer steps, etc.)


2) increase the perceived benefit (communicating benefits, motivating the user)

Geocachers have nicknames they use to sign the logs and in the forum.  Mine is Agilefox – from my days in Wood Badge training in Boy Scouts.  I was in the Fox patrol and was anything but Agile.

Some cachers like to leave signature items in caches to show they were there.  My brother, Team Nutty Dog, leaves dogbone shaped caribeners.  Other cachers spend a lot of money to mint their own coins.  I chose to go closer to the cheap end of the spectrum and make wooden nickels.

I was reminded yesterday of the dangers of developing tools for the sake of tools.  Back in the day when I developed websites for folks, I would be so excited by a new technology or widget I'd found that my instinct was to include it so I could play.  I would add a bit of DHTML or javascript because I found it, not because it did something I wanted to do.  To some extent, I still do that on elsbernd.com, because it's my hobby site. The challenge when working for a client or employer was to ensure the design had as little as possible while meeting the goal, and no more. Anything else is a distraction that wouldn't help achieve the goals of the site.

"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."  --  Antoine de Saint-Exuper

The actual issue yesterday was a project management process.  The process to ensure quality and governance was starting to shape the software development process, when it is supposed to be unobtrusive and stay out of the way of getting the work done.  The software design process was being asked to change to fit the documentation and reporting requirements set by project management.  It didn't help create better code, just better reporting.  The focus was going away from developing useful, bug-free code on time and under budget to completing deliverable documents and passing through review gates.  The project management process was becoming the focus of the activity, instead of being in an oversight and supporting role.  The software development needed more priority, as it was actually developing code for use by the business.  Likewise, the software development process should bend to service the business, not stay so rigid that the business has to adapt to IT processes.

The focus needs to be on achieving the goals of the organization.  No organization has a goal of "developing software" -- they either want to use the resulting software to conduct business or sell that software.  The development process is just enabling the goal, not meeting the goal.  Likewise, while the project management controls are in place to ensure efficiency and effectiveness of the development, they are not an end in themselves, but rather serve the larger goals.  When the wrong things take priority, the goals are not being met.

And lest you think this only applies to software design, remember the same thing in your own life.  My life is not all about designing cool sites.  In part, I do this because I enjoy it, but at the root, my life is about my family and serving the Lord.  I work so I can afford to do those things.  When the job takes me away from the family more than necessary, or when I start to obsess about my job when I'm at home, I'm no longer serving the goals of being with my family or serving God.  The priorities have to be in the right place and remember why you're doing things, or you will be focused on glittery distractions and useless features in this life.

Wow, that got deep.