(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.

So, for the latter half of this week I have been at CodeMash in Sandusky, Ohio. It has been one of the best conferences with traditional-style presentations that I have attended for some time. We have had some remarkable Open Space sessions interspersed throughout the regular agenda. I think most of us are saving up our posts for afterward; it’s been a pretty non-stop pace. The last group I was talking with yesterday wrapped up after 1:00 AM, if that gives you any idea. This has had that same cross-platform, cross-disciplinary feel we had last March at Bruce Eckel’s Programming The New Web. Lots and lots of great stuff. I only hope I can capture a good bit of it and share.

Code Quality, Mentoring, Enterprise Software Management, and mixing Java and .Net carried the day. The format we adapted today was excellent for these topics; we went in roundtable fashion and each participant shared what they do to ensure quality and mentor. After hearing Ben Geyer talk about XRadar, I definitely have to get that set up on my projects at the client site. Someone mentioned the idea of “a build breakage is a line stoppage”; I think it may have been Andrew Moore. That was an interesting concept and hearing how it was carried out in Andrew’s instance was beneficial. Here are the points I shared about quality:

In my consulting/development work

• Reiterating the “sign your work” principle of Pragmatic Programming
• Discipline as a necessary quality; the ability to do what is required for good software yet isn’t fun, intriguing, or stimulating to a narrow attention span
• Use a world-readable version control repository
• Publish the Javadoc and unit test reports to the project website
• Use Checkstyle to enforce conventions
• Use peer reviews for code releases that push to production
• Solid unit/integration/functional testing

This was probably the most public setting where I have shared my observation on unit testing, probably my most original (and distinctly Southern) perspective on quality:

Unit tests are like toilet paper; they have it everywhere I go, but the quality varies widely from place to place.

In my Debian work

• Domain-specific code checkers, lintian and linda
• Using IRC and Nopaste for remote collaboration

The first entry. Huh. Well, if I had known how easy it was to set up MovableType, I would have set this up back when I was originally inspired to buy Essential Blogging from O’Reilly. It actually had the receipt inside the book, so there was no way to deny that I originally meant to start my blog in November of last year. At the time I had three or so topics that I really wanted to write up in posts, two of which I cannot even recall. I do remember wanting to write about the .Net vs. J2EE benchmark from The Middleware Company (TMC) that ruffled folks so much, but that’s so old now that it would be pointless.
Well, perhaps not pointless. There was that invitation for a rematch, and I had been wondering if TMC had not allowed the skewed study and subsequently broadcast their endorsement of .Net in an effort to draw out some of the Java heavyweights for that second invitation to be a real face-off. I also wondered whether or not the tactic (if that was indeed their intent) had enough behind it to succeed. Well, I haven’t seen any more fuss over it in the past year, so it must have fizzled out. If it did, perhaps that is another more timely topic for discussion; why didn’t anyone really care about the TMC study resuts past November of last year?
At 1:45 AM, I don’t really have the drive to hit Google for any news or commentary on it. I did see this one newsletter from a guy in Austin that seemed thorough, if not a bit of a straw man argument on behalf of Microsoft against J2EE. I’m just glad this thing is running.