Value Experience Over Features

As a software developer, it requires vigilance to temper my tendency toward joining feature frenzy. Like you, I like to build features.

My lazy inclination is to forget about asking why or how we justify the new-fangled feature that I'm itching to build.

Features represent our bread and butter, but we are also professionals. We want to be proud of our work.

Since

• our business partners are utterly, in many cases, clueless;
• we aspire to be better professionals; and
• we identify with being craftsmen in the best Alan Cooper-ian sense,

it's up to us to

Value experience over products & features.

How-To Value Experience?

Be an advocate for users. Politely question what's motivating improvements. Are improvements driven from hard data or the soft notions of some muckity-muck over in operations? Resist your tendency to join the feature frenzy.

Let yourself be dragged kicking and screaming before you contribute to BAD user experience by layering in Over-Featured Confusion.

Over-Featured Confusion

Case in point of Over-Featured Confusion is LinkedIn's new and improved Discussions feature.

As soon as LinkedIn released its groups concept, I founded two LinkedIn software groups (i.e., the global Agile .Net Practitioners and the local Twin Cities Software Consultants).

Laudably, LinkedIn has steadily rolled out features that have improved our group experience. Until now...

LinkedIn's new Discussions feature amounts to a ball of confusion. The most glaring improvement is a horizontal slider bar with options to Like, Pass, Comment or More? as a mashup of blog, news and discussion items scroll past (horizontally).

At best, it's confusing. At worst, it's unusable.

• May I Pass on this colossal FAIL by LinkedIn? No.
• Did my feedback to LinkedIn about this improvement disappear into a black hole? Probably.

LinkedIn replaced simple & serviceable with confusing & dysfunctional.

Considerations

As design luminary Don Norman says

Forget the complaints against complexity; instead, complain about confusion.

Perhaps it's excusable to transform something complex into something confusing. But it's inexcusable to transform something simple, like a discussion board, into something confusing.

Google UX researcher Paul Adams says in his presentation Designing Experiences, Not Products

We need to understand how people think, and what motivates them to behave in certain ways. The best way to do this is to design from the outside in. To observe people in their own environment, probing them so that we understand their behavior. This understanding enables us to design things that are meaningful and valuable to people.

Asked or Ignored?

Esther Derby enumerates helpful considerations when Hiring for a Collaborative Team.

I particularly like Esther’s advice to

Involve the team in the hiring process.

Many hiring managers in organizations of all sizes and shapes don't conceive of people working in teams, so it simply doesn't occur to them to ask for input from the team when hiring.

As someone working day-to-day on software teams, I appreciate inclusion in team hiring rituals. A team lunch with a potential hire often smokes out valuable intrapersonal impressions.

Most people would rather be asked than ignored.

Sadly, I've also worked on teams where the morale is so low that team members have a "whatever" attitude vis-à-vis adding new members to the team.

Still, I suspect most would rather be solicited for input.

I value behavior over technology.

A teammate's sense of humor, and professional modesty, is more an indicator of collaborative success than outstanding programming chops.

Microsoft WCF Gotcha

As a WCF newbie, I experienced some wheel-spinning with a service this week. Here's a gotcha that made us swerve into the weeds, along with the solution we implemented.

Our team gained traction developing and running a WCF service under our local Cassini web servers.

Our service was performing as expected.

Well, it works fine locally...

Yet we skidded into the ditch when we deployed our service out onto our IIS web servers. Under IIS, we got the cryptic

This collection already contains an address with scheme http. There can be at most one address per scheme in this collection.

Solution

Our solution was to write a Custom Host Factory that overrides the method CreateServiceHost the framework calls when firing up a WCF service.

A custom host class was derived from the framework's ServiceHost with an override whose purpose is to select the appropriate host vis-a-vis the http context of the server environment (e.g., Dev, QA, Prod).

IIS typically returns a handful of base addresses reflecting any host headers it might have in the Uri array baseAddresses (see above). One of those addresses has to be selected for use. If not, IIS will return the error above. If an appropriate host is not found, a warning is logged to the Windows event log and a default host address returned.

We created the method GetContextAwareAddress to loop through the base addresses IIS returns until we match it with the host of our current http context -- HttpContext.Current.Request.Url.Host.

Remember to wire up the custom service factory in the code-in-front of your service so your service knows to call the overridden, customized CreateServiceHost method.

In our case, the service class is named ProductService.svc.cs and the factory is named ProductServiceFactory as shown above.