People Manage the Process?

Gerhard Basson has posted a very nice article Process-oriented Systems Paradigm for the Process Age over at the BPM Institute web site. I agree with almost everything that Gerhard says... but as usual one little phrase pops out and spawns a blog of my own.

Gerhard asserts:

"processes do not manage people – people manage processes"

I understand what Gerhard means... very clever word-smithing... but I squirmed when I read it. I know that I am splitting hairs here, but "manage" just isn't the right verb for the phrase:

"people verb processes"

That aside, I vehemently agree (as opposed to vehemently disagree) with Gerhard when he says:

"People will bypass and reject any system that does not help them perform work in a natural way."

It's always about the people... From the conception of the process to the implementation of the process to the running of the process to the improvement of the process... it's always about the people.

If we don't adapt our systems for the People of the Process Age we're not going to get very far.

Programming Language Sociology

Bruce Eckel shares his reminiscences about the dawn of C++ and Java in his blog entry: Why? Language Archaeology.

This is great stuff... Insight into the "why" C++ and Java are the way they are (from Bruce's perspective). My take-aways from this essay are the following:

• "Things" often make no sense because the requirements that dictated those "things" are no longer requirements
• People skills can be just as important as Technical skills

I really appreciate Bruce admitting that his opinions about Java are colored by his dealings with Gosling... Social aspects impact Technical aspects. How you feel about someone impacts your evaluation of their work. That is a hugely important thing for us to remember.

I was an early adopter of C++ and loved it... but I loved Java more. Was that due to Java's technical superiority?

Nope.

I loved Java more because it coincided with the Web... and the Web allowed me to collaborate with other Java developers in a way that I had never been able to collaborate with other C++ developers. The social aspect of this collaboration is why Java trumps C++ on my "fondness scale"... Java had (and still has) a much stronger sense of community than C++.

The stereotype of the programmer nerd with poor social skills had a lot of basis in fact... but in my experience programmers really crave social interaction within a society where they feel comfortable.

My programming focus is now in the realm of Business Process Management, so the society in which I find myself is much broader than that of my C++ days. In my C++ days I wrote stuff for business people. Now I write stuff with business people. Huge difference.

Successful Business Programming requires a society where both Business and Technical people feel comfortable. That's tough to accomplish because the passions of those two camps rarely coincide...

Next time you're in a conference with both Technical and Business people, sit back and watch:

When the Business folks get into an animated discussion the Technical guys will be checking their Blackberries. When the Technical folks get into an animated discussion, the Business folks will start looking at their watches.

The challenge in business programming today is not about programming language features - it's about the social aspects of application development. We've got to solve the problem of engaging everybody in the development process. We need to fully engage the Business folks to make sure that we build the right things, and we need to fully engage the Technical folks to make sure that the things are built right.

Compared to the real challenges of business programming, agonizing over whether or not to include the "new" keyword in Java is seems positively "quaint". Bruce's recollections are a fond trip down memory lane for me... but lets not get stuck in the past lest our descendants look back on our concerns as "quaint" too.

Good Engineering != Good Design

This thought-provoking statement grabbed my attention...

"Most tech products—heck, most products in general—aren’t as good as they can be because they’re put together by the people with the technical knowledge required to build them."
Jason Snell, Macworld.com

Jason makes some really good points in this article... Go read it ;-)

Artists (and programmers) hate negative feedback

If you really want to piss off an artist, just tell them how their painting/sculpture/etc. could be improved.

The best possible reaction that you'll get is a politely disingenuous "Thank you"... More likely you'll get some form of "Mind your own business" delivered with various levels of hostility based on the strength of the artist's self-esteem.

The creation of art is intensely personal... Art is an extension of the artist - created primarily to satisfy the artist's need to create. Art is presented to the public - not shared with the public. The artwork may be sold - but it always belongs to the artist.

What does this have to do with Programming?

For many programmers - Programming is their Art... and that's the root of many of the conflicts that you will have with programmers.

There's an anecdote about Frank Lloyd Wright: The story is that he attended a dinner party in a house that he had designed, and before leaving he had rearranged the furniture back to his original plan. Wright couldn't let go... The house was held hostage to his vision rather than released and allowed to become a home. Wright liked to preach that "Form follows function" - but in this case he totally forgot the true function of a home.

When you have to provide negative feedback to a programmer - focus on conveying the big picture: What do you really need? Instead of focussing on how the current software does not meet your needs, challenge the programmer's inner artist to create something that will fulfill your needs... You'll probably be much happier with the results.