Talking Technology to Humans at CodeMash

Barry Hawkins and Dianne Marsh on the opening panel at CodeMash 2008 - Photo courtesy of Michael Letterle

I was invited to be on a panel for a pre-conference talk at CodeMash titled "Talking Technology to Humans: Selling Your Ideas, Products, and Services". Fortunately, I was invited with about 48 hours advanced notice, so I had some time to collect my thoughts on the topic. As I was writing them out on the flight to Cleveland, it occured to me that each of my points would package themselves nicely into blog posts.

So, I'll be doing a series over the next few weeks titled based on my initial discussion points, which are shown below:

  • Believe in what you're selling, and for the right reasons.
  • Keep a long-term perspective; be aware of the "sales cycle"; timing is essential.
  • Software development is not Computer Science.
  • Present your offering in terms of its proposed value instead of its implementation details or groupthink, fanboy hype
  • Never understimate how boring you can be.
  • Prove before you preach; make something work and then tell what it was.
  • Beware proper nouns; stereotypes and prejudices can cloud your message.
  • Know the political landscape and relationship web of your prospect, preferably before you open your mouth.
  • Realize when things aren't a fit, and move on.
  • Don't oversell, neither in terms of capacity nor capability.

Now I just have to come up with a title for the series...

Java and the prodigal son syndrome

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.

Time & Money migrated to Subversion

Over the weekend I managed to get the Time & Money project repository migrated over to Subversion. It was a fun one because the modules needed to be rearranged into the directory structure that the team had worked out. I kept a log of my steps with the goal of turning that into a how-to that may be of help to other Sourceforge projects that have yet to migrate from CVS. I just need the time to make it more of a cogent how to and less of a stream-of-consciousness ramble.

Toilet paper as syntactic sugar and the cost of forks

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.

Lightning talks come to Crested Butte

We added lightning talks to the event, and it's been an excellent addition. From the highly-technical to non-Java-related, these were a blast. I missed the first ones, but this second night was a blast. Joe Nuxoll gave a pretty cool one on racing, specifically the topic of load distribution. I'd like to try some of it out, but not on the actual road. Joe's actually really into racing, and I enjoyed his passion for it as well as the information he shared. Joe Neely of FedEx gave a cool typography talk, and James Ward showed some cool Flex apps.

The day's talks were good as well, but I am not recalling the particular topics I wished to write about.

Skiing continues to be great; did my first jumps and some more mogul black diamond runs today.

Layered Architecture in Java off the server -- not?

One question I have had for practicioners who work in Java "off-the-server" is whether or not they really layer their application architecture for their applications. You hear people throw that use case around for lightweight, POJO-based frameworks like Spring and Hibernate, but I always wondered whether or not that really happens.

If the response to that talk is any indication, the answer appears to be a sound "no". The five or so people that showed up all worked primarily on server-side stuff, and none of them cited any layering of this type within applications authored by their organizations. At a conference about Java off the server, that surprised me.

Overall another great day both at the conference and on the slopes.

So what is a server-side guy doing at the Java Posse Roundup 2007?

The Java Posse Roundup 2007 in Crested Butte, Colorado has the central theme of "Java off the server". Given that topic, why (besides the skiing) would I haul out to Crested Butte for this meeting? In short, I am here because I know what Open Space events organized by Bruce Eckel are like and I know there'll be plenty of topics that are not strictly "off the server". The first day already made good on that prospect. Heck, Python and Domain-Driven Design came up within the first topic I attended.

The initial conversation I participated in was related to the role of dynamic languages on the Java Virtual Machine (JVM) and their integration with Java even in their native implementations. Most folks seemed to agree that the JVM holds much promise as a platform with mature threading and stability for dynamic languages whose C implementations suffered in those areas.

As an Open Space veteran, a meta-topic for me is watching folks who seem to be unsure about whether or not we'll get anything done with this meeting format. I look forward to hearing their impressions at the end.

Skiing this week is excellent! Good snow, not too crowded, good weather; this will be a great time.

Spring as an enabling technology for applied Domain-Driven Design

I wrote earlier about the apparent embrace of Domain-Driven Design (DDD) within the Interface21 team, the group behind the excellent Spring framework for Java applications. I have been thinking about why it is that Spring in particular would lend itself to the application of DDD.

I first expressed this during the review of the DDD track last Wednesday for the start of the conference. The escape from the productivity hit we all took with Java EE when Spring first began to be known was a big deal. The ability to have an layered, n-tier application that was testable out of the application container, with the ability to wire up a bean container's contents via a straightforward XML syntax breathed new life into many a tired J2EE web application. Lines and lines of tiresome boilerplate code for DAOs were replaced with clean, small implementations that extended the appropriate Spring template. The effectiveness of our domain models were about the furthest thing from our minds. Why didn't we immediately address domain modeling as soon as we had our sea legs with Spring?

I would say it's analogous to not being that concerned about what clothes you are wearing when you are starving to death. Remember Maslow's hierarchy of need from basic psychology in college? Few people whose physiological and safety need are not being met care that much about self-actualization. There are enough shops using Spring for there to have been two consecutive conferences dedicated to the technology. Spring is ubiquitious; that was the thrust of Rod Johnson's keynote today. It has proven itself as a productive, viable foundation of enterprise Java applications the world over. Given that foundation, there exists the capacity to ask, "how can we now move to the next level of applying Spring in the best manner possible?" Domain-driven design answers that question.

Domain-Driven Design is not easy, and many, if not most, technologies actually impede the application of DDD. This is where Spring stands out among the raft of framework options. It has always had the intent of staying out of one's way rather than attempt to infuse all of your code with its own prescriptive dogma (insert JSR of choice here). Spring stays out of your way, enabling the necessary insulation of your domain model. Since it is also Open Source software, there's no need to bolster a revenue model by implementing any such ugliness in an attempt to ensure vendor lock-in. The Interface21 group is freed of that burden throughy their choice of Open Source, they are freed to pursue excellence in the code unfettered by a need to drive sales of the software. Since they depend on revenues through services, they are driven to make the best framework possible that will be of sufficient utility for more people to need training and consultation they provide. The model seems quite sustainable, and I wish them the best.

A long-overdue break in the silence

It seems ages since I last wrote. There've been wisps of motivation here and there, but mostly from odd topics or observations. A few things have contributed to that.

My enthusiasm about software development ebbs and flows. At a visceral level, I love the craft. The creative aspects balanced with architectural principles can be fascinating, and are almost always challenging for any problem domain beyond the trivial. However, the forces that wish to subvert and pervert the craft into a means of capital gain sap my energy. At times it's downright depressing.

It's not that I am against earning money by developing software or helping others develop it; by no means. That's certainly how I provide for my family. The thing that totally turns me off is the agenda of most vendors and a certain contingent of programmers to portray software development as a deterministic, engineering process that is easily commoditizable -- if only you buy product X or employ heavyweight, tool-centric methodology Y. That lie has held sway over most of the industry for far too long, at the expense of the craft and all who participate in both the creation and use of software.

Another thing that has robbed me of enthusiasm for close to a year now was an emotionally demanding contract with a challenging client. I had to spend many hours dealing with the effects of the engineering/commoditization myths and the unrealistic expectations and unproductive results they yield on projects. Grinding against that kind of friction left me with precious little emotional energy, and I wasn't willing to spend that on writing and leave my family with even more of a withdrawn shell of a husband/father.

There have been a few things lately that have been a refreshing/renewing force in my software development enthusiasm. The first has been the practice of Domain-Driven Design (DDD). The frank attitudes about the rigors of good software development that best serves the stakeholders with flexible, extendible systems is so refreshing. An acknowledgement of development as primarily a creative process and less significantly an engineering process is a welcome message for me. I have begun collaborating with Eric Evans, author of Domain-Driven Design: Tackling Complexity in the Heart of Software and the person who first crystallized the concept of DDD as a practice. It's certainly been invigorating and I am being challenged to develop my domain modeling and design skills to higher levels.

The practice of DDD in and of itself is great, but enthusiasm for a practice without a community of fellow enthusiasts/practicioners falls mostly to the realm of wistful "shoulds" and "oughts". I am starting to see others, practicioners of the craft whose perspective I respect, also warm to DDD. Their reasons seem sound; they aren't attempting to accrete another buzzword to their repository. For some it even comes at the expense of having to point out flaws in their own past approaches (or those of their employers) to software development. It is my hope that their candor will be rewarded and not punished.

I write this from the hotel lobby of the Westin Diplomat in Hollywood, Florida. It is the day before The Spring Experience, which is the first conference I have seen with an entire track dedicated to DDD. Eric and I attended the DDD track get-together last night with the Interface21 guys, and I am greatly encourage to see how the Spring Framework project has embraced DDD. It seems a natural fit, but more on that in a separate post.