John D. Mitchell's Blog

December 2004 Archives

JCK's New Bait-n-Switch Licensing

Sun's Graham Hamilton has just announced the release of the Java Compatibility Kit (JCK) for J2SE under a read-only license.

Whoopity do!

If, heaven forbid, one wants to actually use the JCK at all, you are required to either submit to the onerous SCSL (Sun Community Source License) or upcoming JDL (Java Development License). If you want to use it commercially, you have negotiate a commercial license with Sun (at least $50,000.00).

Geez, doesn't this remind you of Microsoft's incredibly lame "shared source" insanity?

As always, I'm a firm believer that, hey, it's Sun's property and they can do whatever they please with it but Sun's mealy-mouthed, half-assed, Janus-faced approach to "opening" up Java is, frankly, insulting. Sun: if you want to continue with your dictatorial control of Java, just be honest and say so but stop all of the weasely, self-righteous BS -- or return to your bold roots and get serious about truly opening Java up to the world.

Keys to Debugging

My buddy Terence Parr just published an article on developerWorks called Learn the Essentials of Debugging. In it, he brings up a number of essential debugging facets: Reproducibility, Reduction, Deduction, Experimentation, Experience, and Tenacity. Those six are certainly important but they aren't the whole story.

The first one that I'll add (based on the classic, nagging wife story... :-) is: Ask for help! Tom did what he could to figure out the problem and then he asked for help. Unfortunately, the boys forgot to ask me (an email expert that they know) and wasted a lot of their time -- the quoted-printable issue was the first thing that came to my mind. Doh!

However, like any problem solving process, the most crucial aspect of debugging is a more subtle issue... Admit that there is a problem. Now, obviously, Tom certainly realized there was a problem because he was actually testing his code and paying attention to the results. But, look around you. Have you noticed how many "issues" are missed, denied, and otherwise ignored? Look at the various bug databases (like the Java BugParade) where real, serious issues are ignored or outright denied for years. And, heck, at least someone bothered to recognize those problems and report them. Think about how many problems are completely missed because so many developers do only lackadaisical testing (let alone documentation or design work). Even more insidious are the higher-level dysfunctions such as the head-in-the-sand denials that I pointed out in Anatomy of Insanity?.

Humane development processes attempt to address this issue in various specific ways such as pair programming, code reviews, test-driven development, etc. The fundamental technique is increasing the cyclic rate of feedback at each level so that we will get used to listening to the feedback and then act in response to what we learned.

Rhythms in Software Development

In Fartlek - Increasing your Sustainable Pace, Erik Meade uses the fartlek concept to talk about sustainable pace in software development. However, the notion of fartlek comes from training e.g., runners. That is, the combination of short, intense work interspersed with longer, lower intensity work increases an athlete's ability to perform both in terms of their base level and their peak performance.

So, in terms of training software developers to become more proficient, there is some validity in intensive learning situations so as to point out the need to improve our ways of doing things. However, the fartlek metaphor doesn't really work in the software development world because the stress of high pressure work doesn't e.g, make us more capable of sustaining a faster base pace or increase our peak performance. The facts are clear that the stress induces worse results and more work (due to the need to e.g., fix the bugs introduced as a consequence of trying to ameliorate the stress) both in the short term and over time.

A more appropriate metaphor for what Erik is talking about is the notion of rhythm. Humans, both individuals and groups, function in rhythms. The rhythms come in various granularities such as daily, weekly, seasonally, etc. and various types such as mental, physical, emotional, and spiritual. In my experience, software developers and managers (and the myriad, inhumane "methodologies" that are used) not only tend to ignore the rhythms in our lives but actively fight against them.

For example, one key aspect in the perennial war between computer "languages for dumb people" and "languages for smart people" is how the language designers choose to either put various kinds of straitjackets on people or give folks plenty of rope to hang themselves with. :-)

The key manifestation of rhythm in agile practices is, IMHO, actually the notion of (very) short cycles, both individually in terms of individual task management (via, e.g., TDD) and group project management (i.e., XP's "iterations" and Scrum's "sprints"). The rapid cycling provides the hooks, if you will, of perceiving the reality of what's been accomplished (or not) and choosing how to adjust moving forward.

I leave it, for now, as an exercise for the reader to delve into how the notion of rhythm fits into the software itself and the systems that we create with that software.

This work is licensed under a Creative Commons License.