April 22, 2004

Software subscription model gathers momentum...

A CNet article from April 1, Software subscription model gathers momentum, a growing acceptance of software subscription over traditional licensing.

I think this is a good thing for a number of reasons.

First, it keeps the customer in the loop.

Second, it shrinks the loop, providing better feedback from customer to provider.

Third, it creates an incentive for software producers to be more responsive to customer needs/desires/wants.

In short, it makes it possible to have clients "pull" value from the software development system, instead of having it "pushed" onto them. It gets cheaper to produce software. And maybe ... just maybe (though I don't hold my breath)... we can take the hype out of the product release ritual and instead introduce the notion (just think of it!) that one purpose for a release is to illicit feedback from the customer.

... ummmm...

... maybe not!

Posted by mhamman at 04:04 PM | permalink 

March 05, 2004


"To give your sheep or cow a large, spacious meadow is the way to control him."(Shunryu Suzuki, Zen Mind, Beginner's Mind)
Posted by mhamman at 03:42 PM | permalink 

March 04, 2004

Creativity Needs 'Availability' + 'Friction'

When writing about creativity, a number of people from Martin Heidegger to Mihaly Csikszentmihalyi talk about it in terms of flow, of being fully in the present.

I think that creativity also involves an acute alertness and sensitivity to one's environment--specifically, one's task environment.

Broadly speaking, your task environment is the physical, cultural, social, historical, cognitive, and psychological dimension related to particular work or a particular domain of activity. For example, if working in a chaotic environment, do you think you'll be able to focus? How about working in a space with no bathroom, no kitchen to cook food from, or no faucet to wash your face or hands from? Visit to learn more.

For instance, the task environment for programming includes the languages you use, the tools, the machines (are they fast enough?), ideas, methodologies. It includes your education, and the larger institutional agreements, conversations, and arrangements with respect to which your education comes to have meaning in a wider academic and business environment. the task environment for programming also includes the social environment of those with whom you work, and of the larger organizational and business environment in which people's productivity is translated into valuable resources and services.

So, among the things that creative people work on is their task environment. In fact, most creative people pay alot of attention to their task environment.

There are at least two discernable aspects of the task environment that are of concern:

  1. Availability
  2. Friction


One thing that creative people want is they want to have certain things be completely and totally available. Availability, in this context, doesn't just mean that what you need is there, ready to use. Rather, availability means that what you need at any given moment is so very there, that you don't even have to think about it.

For instance, having the fastest machine and compiler you can get, so that you lose no time at all doing frequent builds of software, makes things like test-driven development and continuous integration (two key principles in agile software development) utterly seamless to what you are doing. Having these things be seamless introduces practices that can lead to uncommonly great software development practices. Whole teams and organizations are affected, and overall results in delivery can be dramatically improved.

The affordances which the fast machine and tools make available not only make work easier--they make possible sets of practices that are uncommonly great. Test-driven development and continuous integration would be too painful to practice with slow machines and compilers. Not impossible--just too painful.

This is the aspect of availability.


The other thing that creative people need in their environment, at least from time to time, is some kind of friction. This may sound like it is at odds with the aspect of availability, but it isn't. They operate on entirely different planes.

When things are always easy, we often tend to become somewhat complaisant. We move into a habitual relationship with what we are doing. When this happens for too long, there is little learning or growth. Stagnation begins to set in.

From time to time, what creative people find themselves doing is somehow rattling   the foundation of how how they work. They reshape familiar tools into something new. Or they throw everything out, and start completely from scratch. Oftentimes, they generate false problems in order to force themselves to think about things from a different perspective.

The history of visual art, music, and science is replete with this kind of activity.

By introducing a friction into an otherwise mastered process, we force ourselves into a different relationship with our own ingenuity and practice. Creative people are good at seeing where to introduce friction, so that it doesn't completely disable their competence, but instead simply makes some aspect of what they are doing less preditable or habitual. This introduction of friction is often done completely unconsciously, though not always (see the example of Jackson Pollock in a previous post).

This is the aspect of friction.

Availability + Friction

Taken as two central aspects of an environment that supports creativity, availability and friction have a dialectical interrelation. Without a powerful sense of availability, as described above, friction will only produce frustration. There needs to be an amply smooth flow in one's environment in order to friction to have anything other than a irritating effect.

By the same token, without the occasional friction, the availability of things in environment can make no real difference. Without occasional friction, the throughput that availability affords is simply wasted.

In fact, wherever creative people are introducing the aspect of availability, they are doing so in order to make it possible for the introduction of friction. Think of those times, for example, when you have a big important project that will require a lot of creative focus. I don't know about you, but one of the first things I do is to structure the environment so that it provides as many points of availability as I can manage to set up. Then, when I start to work, there is plenty of space for me to generate frictions as I go along. The affordances given to me by my now highly available environment makes it less costly and frustrating for the breakdowns, which frictions generate, to occur.


A high-quality hammer offers nothing in terms of availability to one who is not skilled in carpentry.

Simarly, devoting the fastest machines for email and spreadsheets, while software developers are struggling with hourly builds subverts the potential availability which those faster machines might otherwise afford, if properly dedicated.

The quality of availability, as we are describing it, has no meaning if there is no competence related to the domain in which that availability is engendered. That latent availability is transformed into a mere luxury.


Posted by mhamman at 06:58 PM | permalink 

Creativity = Competence + a Desire to Create a Problem

[This begins a series of unrehearsed thoughts on creativity]

On page 90 of his great book Work-oriented Design of Computer Artifacts, Pelle Ehn writes:

"By actively treating well-known situations as if they were something else, or by actively approaching them from a different point of view than the normal, we may produce new knowledge about them. To obtain insight you have to know the practice you are reflecting about. To produce insight requires the competence to reframe something well known in the light of something else."

The question is "how do we reframe things?"

In my recent "former" life, I was a composer (yes, of music). As a composer, I was also an avid student of creativity--I thought about it, studied it, wrote about it.

One of the things I observed was that while creativity as a concept requires knowing something, creativity, as a presence, required that I forget everthing I know. When I was "being" creative, I was mostly stretching my sense of who I am and what seems reasonable. From this observation, I started to conjecture that being creative had something to do with making familiar things seem, at least for a moment, strange.

My favorite example of this is Jackson Pollock. To make his breakthrough paintings, he layed the canvas on the floor instead of stretching it on an easel. Having the canvas on the floor forced him to take a completely new approach to applying paint--he could no longer use the time-honored techniques that were so familiar to him.

For Pollock, the act of applying paint—perhaps the most elementary action in painting—was transformed from something familiar and not at all problematic into something not at all familiar and highly problematic. By turning something familiar into a problem, he changed the occurance of phenomena and of his own behavior.

Unfortunately, most of us are so busy trying to solve problems that we fail to notice that in solving problems we sometimes rob ourselves of the opportunity to learn something new. So, with admittedly a touch of pomposity, I offer a provisional definition of creativity:

Creativity = competence + a desire to create     a problem.

Regarding "create a problem": I often find that created problems are far more interesting to work with than those ones that have been around for awhile, or ones that others bring to me. In fact, in order to get unstuck, I sometimes assume that the "presenting problem" is not even the problem at all--that the problem being presented is masking an underlying problem. If I can find the underlying problem, and work on that, I afford myself the opportunity to learn more about the dynamics underlying the original, presenting problem. In doing so, I can often solve not only the presenting problem, but I can anticipate other not-yet presented problems as well.

Posted by mhamman at 05:26 PM | permalink 

February 24, 2004

Resistance is Gold

In comment to a previous   post, Frank   Patrick writes:

Any proposed course of action that is developed by a finite set of authors can only be improved -- either in content or in implementation -- by addressing the "yes, buts" and obstacles identified by others outside the original group. Soliciting "yes, buts" will help to deal with potentially damaging side-effects to which the original authors might be blind. And obstacles to implementation of a proposal are far better identified so dealing with them can be included in the plan -- they'll be there whether identified or not; better to identify them than be surprised.

Dale Emery has done some   interesting writing on "resistance". One thing Dale observes is that the very expression itself of resistance contains a lot of hidden information. For instance "It can't be done": what does that mean? It is a statement which, if its speaker is open to exploring it, is information-rich. Same thing with "I don't have enough time."

 Following up on such statements -- treating them as information-rich -- allows us to learn what people really think and feel about a project. This information is GOLD, because often those deeper, niggly feelings and hunches bear foundational truths which we ignore at our peril.

Resistance is not only a valuable barometer--it is a fountainhead of discovery. However, its productive mining and utilization requires an uncommonly human-focused approach to project leadership. I value David   Schmaltz as a great source for such a human-focused approach to project leadership. His website is great, as is his book The   Blind Men and the Elephant.

Posted by mhamman at 01:24 PM | permalink 

Change, Manglement, Resistance

Reading Andrew Pickering's The Mangle of Practice, Brian Marick    writes
When you do things, you do things to things. You tweak, twiddle, or frob them.In the course of moving toward the goal, people encounter resistance. It's not just people pushing at the world (broadly construed); it's the world pushing back. That sounds pretty trivial, but Pickering is asking us to take Kent Beck seriously when he says (as he does in Smalltalk Best Practice Patterns), "Since the code seems to be telling us to do this, let's try it." (p. 3)
Later on we find thisI like where this is going. It reminds me that
  1. our activity really does add something to, or otherwise change, the world (and ultimately ourselves); and
  2. resistance is actually a good thing because it tells us what the world really thinks about what we're trying to add or change.
More later on this....

Posted by mhamman at 11:07 AM | permalink 

February 18, 2004

Project 'Rhythms'

In her weblog post Project Rhythms and Working Your Own Project, Johanna Rothman's draws a nice analogy between the different rhythms of football teams and projects.

Johanna writes:

"If you watched the SuperBowl Sunday night, you had a chance to see two different teams play their own games to their own rhythms. The Panthers have a long-pass, long-run, elegant rhythm to their game. The Patriots have a short-pass, short-run, nibbling-up-the-field rhythm to their game."
Each team stays in the game by working the rhythm that best fits them. Trying to work some other rhythm defeats the teams abilities.

In his response, David Greenfield writes:

"It's not about avoiding the obstacles (though it's good if you can do it) but about recovering as fast as possible."

David also asks "Is it rhythm or momentum you're talking about?" An apt distinction.

You can keep to the same rythm and go faster or slower. A grooving team can maintain its rhythm--not stumble--as it speeds up or slows down.

A REALLY grooving team can coordinate changes in its rhythm (as well as its momentum) as it responds to obstacles or other changes in the game. For instance, the Panthers may have, at some point, changed its game plan -- its rhythm -- in response to events on the field.

The ability for a team to change its rhythm in a coordinated way may have advantages over teams that can only maintain the same rhythm, all else being equivalent.

Very nice analogy, Johanna. Thanks for offering it!

Posted by mhamman at 04:05 PM | permalink 

Loves Technology, Hates People

If it is your impression that some executives like technology more than people, you may be right.

In the January/February (2004) issue of Business 2.0, Jeffrey Pfeffer writes "Whenever I teach executive seminars on the importance of building a great company culture, I spend most of the time, strangely, listening to reasons the participants are so reluctant to give it a try. Changing the culture takes too long.  People don't like to change.  It requires too much time from top management..."

As Pfeffer points out, none of this is true. If their organizational environment isn't working--and if they can feel the pain--people are pretty open to change, as long as they feel genuinely a part of it.

The problem is that many executives are addicted to technology. And, in their zeal to "upgrade" everything, they tend to forget the needs of people who have to deal with the resulting monstrosities.

Consider what's now happening at the University of Illinois at Urbana/Champaign. There, they've spent a couple of 100's of millions on their new "integrated" software system called Banner. Great idea!

But it stinks.

It is clunky, cumbersome, buggy. It could provide an entire Human Factors conference worth of examples on how not to design human-facing systems. The cost in hours lost in using the system, and the degradation of morale across the entire university (everyone hates it) has wreaked untold damage to the university. I have heard that a new illness has surfaced from it: Banner-Induced-Stress-Syndrome (BISS).

Pfeffer wonders why executives can lavish so much money on technological changes that demonstratably degrade organizational performance, while refusing to spend considerably less on cultural and organizational initiatives because of its reputed costliness and potential for causing organizational dis-equilibrium.

Could it be that instead of dealing with people issues straight on-which some see as not very sexy-some people prefer to throw a whole bunch of technology toys at it, hoping to cover over the human organizational problems?

Pfeffer concludes, quoting a study conducted by Erik Brynjolfsson of the Sloan School of Management:

"Companies that have great information technology and great management practices do wonderfully. Companies that have lots of IT and bad management do the worst-because, Brynjolfsson found, the strength of an organization greatly magnifies the return it gets from capital investments in IT.

Technology amplifies the weaknesses of a weak (or demoralized) organization, just as it amplifies the strengths of a strong one.
Posted by mhamman at 01:55 PM | permalink 

Late-Binding on Projects (I.e. 'make commitments at the last possible moment')

I'm finally getting to a series of blog posts by Hal Macomber from last September, Designing Breakdown-Tolerant Project Environments (I).

Hal defines breakdowns as "an interruption while in the midst of fulfilling ones commitment, jeopardizing the completion of the commitment."

One way to think of projects is as the collection of commitments whose fulfillment is required for the project to complete successfully. Without the fulfillment of commitments, projects cannot succeed.

Hal takes this to the appropriate extreme: he suggests that we delay making commitments until we know their fulfillment is necessary for the project's success.

"The more commitments we have open at a given time the more likely it is that one will become in jeopardy. Delaying making commitments reduces the overall probability of a breakdown. Having reduced the overall probability of a breakdown we are now in a condition to be more responsive to the breakdowns we declare."

This is akin to practices in XP and Scrum, wherein we delay making business decisions until we have to deliver something.

There's another part to this. Hal distinguishes commitments from promises. Promises are a conversation we have with the client regarding "the value the client will receive by when, for some agreeable price." Hal writes:

"We might not even have to say what the product or service will be that provides the value. Only that the client will get the value intended."

This resonates Rob Thomsett's distinction of Output vs. Outcome (see
Radical Project Management, pp. 102-104. Output is the work produced by a project. The Outcome is a mapping of that Output to a declared value. For instance, reduced highway accident fatalities may be the intended Outcome of a highway safety initiative. One way of getting that is by lowering the state speed limit. Average reduction of highway speed is the Output; if this measure is observed to have reduced highway accident fatalities, then the Outcome is achieved.

However, reduced speed-limits is not the only way to achieve the desired Outcome. It could also be done by improved road surfaces. Or it could be done by expanding safety requirements for all automobiles. Or why not produce a vastly improved public transportation system, thus reducing the number of cars on the highway alltogether.

The point of distinguishing Output/Outcome and commitment/promise is two-fold:

1. that we can delay making critical decisions until we absolutely need to. This make projects easier to manage; and it allows us to be more responsible to the dynamics of the particular project-new things we learn about the customer's declared value, the strengths and character of the team, changes in the technology or business climate.

2. We avoid commiting ourselves to a particular way of getting the job done. If we think that the only way to reduce highway fatalities is to build a new, vast public transportation system (which I think would be a GREAT idea!), then the expense may lead us to assume that the goal of reducing highway fatalities is too expensive, and then just give up on it.

Distinguishing Output and Outcome - commitment and promise - can give projects a lot of room to work. All-to-often, however, these distinctions are collapsed: Output and Outcome are the same, as are commitments and promises.

How might projects (software and otherwise) be improved just by making these distinctions? Even better, project members might ask, Given this desired Outcome (promise), why are we generating that particular Output?

Posted by mhamman at 01:12 PM | permalink 

Promises vs. Guarantees

Frank Patrick, in a recent article writes:

The fear of promising the unknown results in either irrational promises that stress out those tasked with delivery, or unresolved promises that stress out those who must run the business or sell the product the project is intended to support.

In the common world, promises are equated with guarantees. This seems sensible: projects rely on what we can guarantee. However, by treating promises as mere guarantees, I'm wondering if were not robbing ourselves of an important linguistic means for fostering personal evolution, and breakthrough performance. Continue reading "Promises vs. Guarantees"
Posted by mhamman at 12:22 AM | permalink 

Recent Articles
Creativity Needs 'Availability' + 'Friction'
Creativity = Competence + a Desire to Create a Problem
Resistance is Gold
Change, Manglement, Resistance
Project 'Rhythms'
Loves Technology, Hates People
Late-Binding on Projects
Promises Vs. Guarantees
A View From Nowhere
Language and Work I: Intoduction
 Language and Work II: Distinctions
Language and Work III: Conversation
Language and Work IV: An Example
Language and Work V: Promises
"Management" and Ecosystem Design
The Affordances of Paper and Mess
 Information Ain't Context-Free
 Ecosystems Redux

Aesthetics and Tools
 Agile Software Development
 Patterns and Centers
 The Business of Technology
 Technology and Culture

April 2004
March 2004
February 2004
January 2004
August 2003
July 2003
Part of My Constellation...
Agile Alliance
Alistair Cockburn
Artima Weblogs
Brian Foote
Brian Marick
Dale Emery
Esther Derby
Extreme Programming (Ron Jeffries)
Extreme Programming (Don Wells' 'Gentle Introduction')
Frank Patrick's weblog
Hal Macomber
LeanConstruction Institute
Lean Software Development
Pattern Language (C. Alexander)
Pragmatic Programming
Sarah Allen's 'Ultrasaurus Blog
The Systems Thinker
UBOWEB (Contemporary Poetry)
Usage Centered Design
Syndicate this site (XML)
Creative Commons License
This weblog is licensed under a Creative Commons License.
Powered by
Movable Type 2.64