This blog has moved

The new site is http://softwareandbeer.com

This Blog Has Moved

The new location is: http://softwareandbeer.com

Business of Software 2009 (speaking of culture)

..speaking of culture..

Check out Business of Software 2009 promotional video. Money quote:

The business people have no hope of learning the technology. It's just too much. The hill is too steep to climb. That means for a software company to be successful, the people at the top I believe have to be software people, they really have to be the technologists. But they also have to have business skills. So they're just going to have to learn them.

The problem lies less in the competency and more in the culture..

(Hat tip to Sean Rees for the pointer to this episode of "good intentions gone bad in the world of design")

This is stunning. Take a look at this blog post. This guy takes it upon himself to complain to American Airlines about their horrendous web site. And makes a pretty good case that their CEO should be ashamed, and they should fire their designers.

Dear American Airlines

But then a (seemingly) competent User Experience specialist at American Airlines replies. And points out that “The problem with the design of AA.com, however, lies less in our competency .. and more with the culture and processes employed here at American Airlines.” The critic goes on to lament AA’s cultural problems—saying they start at the top and permeate the organization, overwhelming whatever talent may exist in the company. He says, “I feel sorry for Mr. X. and every other employee with a personal ability better than that required -- and allowed -- by the culture at American Airlines. But I don't see customer experience improving without some major, sweeping changes.”

Dear Dustin Curtis

Disruptive change and other links

Harvard Business Review has a collection of articles by or with Clayton Christensen on disruptive change. You might know him from The Innovator's Dilemma. These articles span 1995 to the present, and cover the (mostly technological) impact of disruptive change and continue through the organizational and business response needed to deal with them. The set is well worth the $17. The book is worth the money too, but I think the articles expand past the product/marketing implications and into the necessary cultural transitions as well.

Beyond the ruthless dissatisfaction we all seem to have with Apple's App Store, App Store Mercenaries goes into some candid thoughts on what qualities of work we should value from testers. I was really interested in this stuff when I managed a test team.

I enjoyed this interview on HDcctv vs. IP video with Todd Rockoff--who doesn't seem to have a filter. I have to agree with most of his not for nerds position. This is a particular challenge for us as we attempt to transition from catering exclusively to the "cool guys" to catering to these "nerds" as well. :-)

I can't really disagree with this piece on Video Analytics: Business Intelligence + Security as we're an analytics vendor. But I have to say that these pieces sprinkled with the high school yearbook pics always make me cringe.

I'm kind of tired of hearing that IT managers are more involved in physical security. I'd like to know more about what said managers actually value, and how they make purchasing decisions.

Good stuff from Cisco CEO John Chambers. In particular I like this bit about how he was pushed into blogging:

I thought I was very leading-edge in terms of how I communicated. My team just kept pushing, and I finally said, “Why do you want me to do this?” And they said: “John, if you don’t do it our company won’t learn how to do this. It won’t be built into our DNA for the way we interface with customers, our employees. The top has to walk the talk.” I was expecting text blogging and we did video blogging.

It's important that something as fundamental as how you communicate with customers gets support from the top down.

Finally, I know a lot of people who are excited about the things we're doing to globalize operations (more so than just international sales offices). Not unlike what Samsung's talking about in Thailand

Computer Programming as Stochastic Art

Apparently the ancient philosophers used the word art to mean a body of knowledge about a subject that enables the artist to achieve a particular result. Art was broadly applicable to most any organized practice that people might undertake—what today we rather call vocations or professions.

But the ancient philosophers had a nagging problem. While they could easily criticize a shoemaker for failing to successfully create a pair of shoes as being insufficiently skilled and knowledgeable about their art, they had a hard time convicting a doctor of being insufficiently knowledgeable of medicine simply because their patient died. Thus a debate ensued about how to judge an artist’s skill based on some other criteria than the results of their practice.

The ancient’s coined the term, stochastic art to differentiate those arts in which the knowledge and skill of the practitioner could not be measured simply by the results of their work. They were particularly interested in this idea as it relates to the art of rhetoric and oratory (a form with which some Greeks had a famous obsession).

Stochastic means to “guess at.” But in this context it means, “to aim.” The point being that the aim of the artist is as important as the results, even if they miss their target. And that significant credit can be given to the methods they use, regardless of those results.

Aristotle himself used a lucid example when he said that the product of medicine is not health, but the practices that move the patient as far towards health as practical for the circumstances. He went on to say “It is possible to give excellent treatment even to those who can never enjoy sound health.” (Rhetoric 1355b)

So now we’ve got a framework in which we can categorize art forms. Anecdotally it appears that productive artists like blacksmiths and cobblers can be more easily judged based on the product of their work, while problem solvers like mechanics, doctors and politicians need some latitude to recognize their skill and knowledge as distinct from immediate results. One can recognize an excellent oncologist, even if the majority of their patients tend to die.

Thus the light bulb that illuminates my dim wit, and says computer programming, and probably other specializations of IT, may fall into the category of stochastic art. Keys to the distinction are complexity, problem solving, creativity, and an artist-subject relationship atop a substrate of deeply technical subject matter. This perspective provides a possible out from the dilemma of why writing software does not fit well into the model of building a bridge or a sky-scraper. It may also be a useful tool to help explain other problems with IT that we break our pick on every day.

Doctors, like programmers, are people with deep technical knowledge who rely on their experience in a search for specific solutions to problems. They’re constantly looking for solutions in an ever-changing environment. To make things more challenging for the programmer, their art is probably less episodic than that of the doctor. The programmer must deal with the code they write during spurts of creativity and action from the day they write that code forward. This perspective, for example, provides insight into the central tenant of refactoring in agile methods. (As an aside, note that we're not talking about Stochastic Programming here--that's a different animal).

Additionally, some people believe that the majority of IT projects are failures. Typically, when they survey the beneficiaries of a project, those beneficiaries report to be dissatisfied with the results. While the IT professional might have used the proper methods, they may have missed the aim for a variety of reasons external to their control. Just as most oncologists’ patients die, most IT professionals' projects fail?

This isn’t a mea culpa for the programming community’s failures. In Scientific Failure, James Allen writes that: “failure..led to revisions of the conception of an art itself and the associated notions of artistic knowledge and expertise.” What can we learn from looking at IT from the perspective of stochastic arts and analogues like medicine rather than traditional engineering arts?

For example consider the problem of project management in software development. Imagine if a project manager developed gantt charts and task lists for a team of medical professionals attempting to diagnose and treat a patient with a degenerative neurological disorder. Like most software projects the problem solving, testing, diagnostic attempts, treatments, and the patient themselves simply may not cooperate with the best laid plan. And in the case of something like Alzheimer’s, the project is probably destined for failure if you use the obvious success criteria.

But medicine isn’t all ad-hoc. Methodological techniques and protocols exist in medicine that attempt to provide some deterministic quality to the practice. For example, how do doctors put a schedule on their treatments? There’s probably a lot to gain from the perspective of computer programming as a stochastic art. We should look for examples of stochastic arts and non-stochastic arts and compare and contrast them with computer programming. We may learn from that exercise.

How Integrated Are Your Customer Experiences?

When I worked in banking I learned a lot about the tricks banks use to coordinate the sale of their products to customers across the bank's various contact points with said customer. The part I worked on was to address the ability of the bank to integrate IT systems to promote products to you via a variety of outlets: printed inserts, prompts to tellers, ATM, the bank's web site, etc. The holy grail was a system in which promotions were not sprayed at you shotgun style, but rather if you said "no" to the ATM prompt for a credit card, the teller would know not to bug you about it when you walked in the branch. Banks also want to individualize their promotions to your lifestyle, net worth, etc., again via a coordinated effort across the bank's various contact points with you. Wells Fargo, for example, is getting really good at this.

Peter Merholz has some more on this in his HBR blog post entitled
How Integrated Are Your Customer Experiences?. Of particular interest to me is the discussion around "Channel-specific organizational silos rarely have incentives to coordinate their activities."