(This is part two in a series I have titled “Soft Skills in Software”, which came out of points I came up with for a panel discussion at CodeMash 2008.)

When introducing change in a technology practice, you can save yourself some frustration by being aware of the “sales cycle” for new ideas within your group and maintaining a perspective that always bears the long-term in mind.

As technologists, we often have great enthusiasm for new ideas that we perceive to hold value in terms of their (potential) positive effects on our work. The value is so apparent to us that we often see no reason not to put this new idea to work right away. However, the speed with which a new idea can be adopted is affected by a number of factors. Let’s start with these:

• The organization’s general disposition toward change
• The change agent’s standing as a thought leader within the technology practice
• The resultant impact of adopting the idea in question
• The temporal context in which the new idea is introduced

Depending up on the value of each of those variables (and more), the length of time it takes for a change to be adopted can be anywhere from a few weeks to months to years — or a special category I have, “not for the foreseeable future”. I use that category instead of “never”, because there have been times when I thought there was no way a given thing would ever happen, and suddenly a merger or regime change or some other major external change suddenly opened the door for the previously-infeasible.

I use the term “sales cycle” because it was in a previous career of mine where I first learned this lesson. I used to sell industrial packaging and marking systems, and when I first started, I was greatly frustrated at the seemingly low number of sales that I would close. I would follow up with some clients to the point of irritating them, convinced that “something should have happened by now”. I eventually learned that the different types of systems that I sold had different sales cycles. Because of a given system’s cost and the role it played in the manufacturing process at large, there was a minimum amount of time it took to get approval, move through a cusotmer’s procurement process, and finally issue me a purchase order. Some systems took 4-6 weeks to sell, while others were 6, 12, and even 24 months. In general, the longer the sales cycle, the bigger the sale. Once I understood this, I found myself far less frustrated, and there were fewer of those awkward interactions between my customers and I.

Introducing new ideas to your development group is quite similar. There is a direct relationship between the level of change and the time it takes for a team to agree and then adopt the idea. I have witnessed more than a few programmers who had good ideas that they presented and expected everyone to just approve right away. Their frustration with what they perceived as stalling and/or rejection typically resulted in undesireable outcomes. Even the most-valued technical person is only indulged a few temper tantrums before being labeled as “damaged goods”. Recovery from this sort of thing within an organization is discouragingly rare. The person is usually avoided in discussions about strategic direction, and their ideas are usually dismissed or stifled. In general, if letting person Y talk about changes has resulted in discomfort in the past, the typical solution is to just not let that person talk about changes. It’s warped, dysfunctional, and counterproductive, but that’s mainstream corporate culture for you.

One area where technical change differs from sales is the possibility of incremental change. It’s not always possible to sell only a piece of a large system; changes in software development, on the other hand, are well-suited to incremental change. Being able to adjust one’s expectation from demanding a single big win to being content with a series of methodical, steady, small victories is a valuable skill in software. For some big changes, that can be the only way to introduce them. For example, a company may not be open to switching to Agile Software Development overnight, but having daily stand-up meetings and developing in 2-week iterations certainly seems benign enough.

Having said all that, there have been times where something with a 12 or 24-month sales cycle was adopted immediately for me. Urgency, crisis, severe failure with the current situation, any number of things can result in exceptions to the rule. The art is knowing when to spot these factors and acting appropriately to leverage them. If I could sum all that up in a blog post, I’d probably be in a different line of work ;-).

So tomorrow I fly out to Cleveland for the 1-hour ride to Sandusky, Ohio for CodeMash. The first CodeMash ever took place last year, and I was very glad to have been a part of it. I had intended to submit proposed talks for this year, but alas my schedule was already a bit full and I honestly lacked the energy to put together the topics I would have wanted to present. I cannot wait to be there, several of my colleagues from Bruce Eckel’s OpenSpace conferences will be attending.

One benefit of being an independent consultant is that I am able to choose the conferences I attend without having to justify it to some management or department head. Most of the things I choose to attend would probably not be approved by an organization that insists on being able to directly relate the entirety of a conference’s content of focus to the attendee’s daily tasks. Still, there are numerous conferences throughout the year that appeal to me, and I can only afford to be unbillable for a certain number of weeks out of the year. CodeMash makes my shortlist, and here are a few reasons:

• CodeMash is a multi-language conference. There’s a breadth of exposure and a cross-pollenation of ideas that are simply not available at single-language events.
• The attendees drawn to such events are typically more open-minded about software development approaches and the fact that there is no “one way” or “one language” for anything.
• The speakers drawn to this type of conference tend to have a perspective that is broader and more in touch with software development realities than insisting on foisting some delusional monocultural vision for their language/platform/tool of choice.
• There’s a strong OpenSpace element to CodeMash, and I have experienced first-hand how amazing and energizing it can be.

So, that is why I am going to CodeMash. Looking forward to sharing my experience with my readers, all three of them.

Ever hear the parable of the prodigal son? If you have had any length of exposure to the Christian New Testament, the answer is probably yes. It’s this one parable Jesus shared, captured in the Gospel of Luke, chapter 15, verses 11-32. A depressingly large contingent of the Java™ community shares some annoying similarities to that prodigal son.

The parable is actually about two sons, not just the one who ran off with his share of the inheritance and blew it. There’s also an older son, who was always a good worker and didn’t run off. When you hear someone speak about this parable they usually point out how he’s bitter that the family celebrates when the kid who blew half of everything finally returns home, and that you shouldn’t be that way, et cetera.

A friend of mine once pointed out to me this subtlety; only the father comes out to speak with the older son. The younger son, who has just received this abundantly merciful treatment by the father, makes no gesture to come out and reconcile with the older son. He has quickly forgotten what it was like to be the alienated one. My friend John called that the “prodigal son syndrome”; I think of it often when I listen to and/or read reactions of Java ™ programmers to…just about anything other than Java™.

For those in the “Java™ will never cease to flourish” camp, recall some of the scoffing you experienced back in the early period of Java™’s adoption, the jeers from the C++, C, and maybe even COBOL camp, depending upon the nature of the shop you were in. Now, take those scoffs and perform a search-and-replace:

s/Java™/{Ruby,Rails,Python,etc.}/ && s/{C,C++,COBOL}/Java™/.

Listen to yourself when you respond to topics like Ruby on Rails. The resemblance is unsettling, don’t you think? Why must everything new (or non-Java, really; newness isn’t even a condition most of the time) be rejected out-of-hand as inferior and “a fad”? The unwillingness to acknowledge (much less embrace) the strengths of alternatives to Java™ ironically serve to undermine your puerile assertion that Java™ is the be-all, end-all in programming.

The ardent defensiveness in the Java™ community’s response to Bruce Tate’s Beyond Java™ awhile back is an example of what I am talking about. I’m too busy these days to catalog some of the shining examples from java.net and TheServerSide. But good grief, people, drop it already! And don’t be embittered when you’re overrun by the changes you continually dismiss as inferior to Java ™. There’s an open cubicle down by that grumpy COBOL guy; maybe you two can commiserate.

NOTE: Apologies in advance to the sed crowd for my cruddy syntax above.

So tonight I finally received the PayPal info to get registration set up for AJUG’s Open Space event “The Practice of Java in Atlanta“. I am looking forward to facilitating this event; the rich pool of Java talent in Atlanta should make for a passionate, dynamic group to hold conversations about Java and where it’s going. If you’re going to be in town, I can assure you that the $75 (US) will be worthwhile.

The last day of the Roundup was a lively one; perhaps the most lively in terms of sessions. Two of the talks I attended were centered around the possible forking of Java and Java Applet deployment in view of whether or not it’s too late for rich Internet applications implemented in Java. It was a fun morning; I highly recommend the audio for these two sessions.

It was intriguing to listen to the postulations and concerns of participants over the possibility of Java forking. The majority of them are not participants in Free/Open Source Software; they would fall mostly into the majority category of consuming F/OSS, which explains many of their concerns. I pointed out that forks of significant projects are very costly, and must have their own community with a very good reason for undertaking such an arduous effort. In my view, the governance of Java as F/OSS will be what determines whether or not if forks. I believe some long-standing F/OSS projects’ histories bear that out, based on what I have heard and read of Emacs, mutt, and similar projects. I think the parallel existence of the Java Community Process and open-sourced Java is going to be an interesting sociological experiment over the next years; personally I don’t think they will coexist that well for that long.

In the discussion on Applets, we got into the issue of Swing’s lack of a viable component model. One participant postulated that Swing was just fine when you “have experts who know what they’re doing”, and that (plus the 2 awesome 16oz. caffe americanos I had from Camp4 Coffee) prompted me to express the following view which I now share publicly before the rest of the world:

With all due respect to my fellow conference attendee, my view is that this “when you have experts” sentiment is a key reason why Java has only gone as far as it has. The bearded road apples (props to Scott Adams for that term) who insist on building their own everything have labored under a severe misapprehension. This particular air of condescension is what irks me the most within the Java community. It is that same spirit that disparages meaningful, productive suggestions as “syntactic sugar”; I hate that. Let’s apply that reasoning to another area of everyone’s everyday life.

Toilet paper is syntactic sugar. There’s already an adequately functioning alternative for that given task, namely one’s hand. So why not use that? It works, doesn’t it? Yes, but I find the “syntactic sugar” of toilet paper to have a compelling “value proposition” (props to Joe Nuxoll for reinfecting my mind with that term ;-) ).

I don’t want to wipe with my hand, and I don’t want to use Java as my language for rich Internet apps, web applications, or anything else that is not heavy lifting to which the Java language is well-suited, which seems to be an ever-dwindling category of problem domains. The fruition of the dynamic has arrived; embrace it, you’ll be glad you did.

It’s been a great week; another wonderful Open Space event. Thanks, Bruce. Thanks, Java Posse. See you next year I hope.