John D. Mitchell's Blog

Patterns Archives

FindBugs in Anger

If you aren't already using Findbugs then hopefully you've at least heard about it by now and have some idea of how useful it can be.

If not, then let me say that FindBugs is a must have tool in the arsenal of any Java developer and any development team that's not using it as part of their regular development practices is incompetent.

Bill Pugh has done a fantastic job making FindBugs a great F/OSS tool which helps detect a large variety of all too common programming mistakes in Java.

You can find an online demo, slides from last year's FindBugs introduction , and can even run FindBugs over the web.

If you aren't yet convinced that FindBugs is really useful, let me point out that I've used FindBugs as an expert witness in cases where outsourcing projects had gone wrong and people were arguing about the quality of the delivered code (among other things). You have been warned. :-)

Go wild!

Humane interfaces, simplisticity, and domain languages

Elliotte Rusty Harold has touched off a small war in his response to Martin Fowler's recent entry on so-called Humane Interfaces.

One facet of the debate is an example comparing the equivalent "List" classes from Ruby (Array) and Java (java.util.List). Java's list class has 25 methods while Ruby's has 78 methods. Martin uses that fact to conclude that Ruby's list class is somehow more "humane" while Elliotte's thinks it's just bloated and that a minimal interface is better in terms of how people work.

Martin's primary argument for the "more is better" approach is that:

Humane interfaces do more work so that clients don't have to. In particular the human users of the API need things so that their common tasks are easy to do - both for reading and writing.

More buttons/methods does not make an object more powerful or more humane, quite the opposite in fact. Simplicity is a virtue. Smaller is better.

As you might have guessed, I think both of them are partially right and that there's something even more important that they are really bringing up that should be discussed.

For example, list.first() is actually more humane/usable/readable/etc. than list.get(0). Why? Because the intent needs to be clear and obvious to humans, not just the compiler. Even worse, crap like list.get(list.size() - 1) is just plain wretched compared to list.last() -- intent, clarity, complicatedness, easy to get wrong (off by one), etc. Also, look at how many parts of the list abstraction are "leaked" in just those two examples such as linear positioning, indexing, zero based indices, the first element is "always" at position zero, reliable sizing, etc.

However, Elliotte is completely right that having 78 methods in any class is an atrocity. Something that has that much surface area is way too complicated for humans to keep manageable. In addition, it also sets a bad example for coders learning the recommended ways of doing things -- i.e., "just throw anything you feel like in there."

Going to the opposite extreme of a bare minimum, necessary set of methods is also too simplistic. For example, Elliot throws downs an image of various remote controls, two fairly complicated "universal" remotes and a minimalistic one from Apple. But, who gets to chose what that minimal set will be for everybody? In software, almost everyone will end up wasting time and introduce bugs by writing their own versions of truly common bits of code. Software is, in this regard, much more of an engineering practice than a mathematical reduction.

Hopefully it's obvious that there's a reasonable middle ground. Like any good standard, deciding on what to put into the core library should be about codifying truly common behavior rather than what might sound good to any one special interest group. Other important tools in this effort are things like good design principles and refactoring. [I find it ironic that Elliot brought up the issue of refactoring in a debate with Martin.] Also, the both extremes miss out the addressing the specific needs of the context in which the code is being used: a pro using something everyday vs. a serious hobbyist vs. a random user vs. a half-blind grandmother with rheumatoid arthritis vs. .... Context matters.

Alas, arguing back and forth over those sorts of details makes it easy to miss a fundamental, crucial point: no software (library, application, language, operating system, or whatever) can be all things to all people. Fighting that war is not only pointless but is one of my definitions of insanity. The point of a chunk of good software is to enable the effective and efficient creation of more good software and to help inhibit the creation of bad software.

So, how do we then build up our own code to fix whatever shortcomings we find? Build our own libraries on top of whatever the core gives us which provide the clean abstractions and domain specific languages to get our jobs done, well.

DSLs feelin' groovy (or, graduating from elementary school)

Ben Galbraith has posted the first of a series of blog entries about How I Learned to Love Domain-Specific Languages. It's great that more and more people are starting to see the value of explicit, focused languages over ridiculously inhumane "formats" like XML. Hopefully, we're finally reaching a tipping point.

Explicit DSLs feel weird to a lot of programmers because there's been so little mainstream focus on them. I.e., as shown by one of the comments, developers have been herded and otherwise sucked in by shiny-looking tools (by poor education, management, laziness, peer-pressure, ignorance, lack of training, marketing hype, etc.) and haven't (consciously) realized the power of domain languages. It's amazingly odd to me how little energy has been applied to languages among mainstream developers given how much programmer time is spent arguing about the minutia of programming languages and tools.

The fact is that we're already surrounded by and are constantly implementing "DSLs". Look at the "language" of printf and friends, the declarative "specification" of makefiles, the myriad "protocols" that we deal with everyday like HTTP, SMTP, SSH, and FTP, the "APIs" of code libraries, the "design patterns" embodied in frameworks, the analogies and "metaphors" we use to described software architectures, the implicit languages that we create each time we define a class, the jargon we use to talk with each other, etc.

A big part of the problem that I see happening right now is that too much of the discussion around "DSLs" is being framed as some sort of "either/or" / "black/white" conflict when it's really just a more conscious and explicit approach to things that we've already been doing. Whether it's the hype juggernaut of Ruby on Rails or the Java is old, boring, bloated, etc. ideas exemplified by Beyond Java or the "IDE" wars between Eclipse, NetBeans, IntelliJ IDEA, and Emacs, or whatever, the biggest issue with this "us/them" thinking, IMHO, is that people are fighting the wrong fights. The leverage that matters most is the ability of developers to think and communicate clearly with themselves, each other, systems, business folks, and users. Biologically and sociologically, human are built to be linguistic.

That is, languages are fundamental to how we work internally and with each other. Sure, we have various tools to help us communicate but isn't it clear that e.g., PowerPoint isn't the point, it's just a tool — and, alas, a tool that usually induces poor communication rather than enriching conversations). On the other hand, look at the "modern" killer apps and how they are all about helping us (manage our) communicating: email, web, blogs, P2P, wifi, cell phones, faxes, VoIP, agile/XP, open source, etc. I.e., we've graduated from the elementary school building blocks (word processing, spreadsheets, databases, Belief of Control, etc.) to the middle school of communication. Now, we just need to learn and develop languages and tools built around this new level of understanding and put aside our old, comfortable, but ultimately dead-end habits.

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.

Thanksgiving, Reuse, and Slack

In Leftovers, Dan "Superman" Steinberg brings up the question of how to deal with reuse in this age of agile, lean development.

One trick is to just have a really good memory. Alas, given that most of us are human, that doesn't seem to work too well in practice. :-) Given that we're tool users and creators, we do have some options in helping us remember. A classic is a catalog of index cards -- the post-modern equivalent: a big junkyard of code (and you do, of course, keep *all* of your code in a repository, right?) and a local search engine. Another trick is creating and using an orphaned code wiki -- i.e., if the code is something interesting enough to save, add it to a wiki.

Dan asked "With coding - how do we think of reuse? Are we at a point where we start planning for our code leftovers? XP teaches us not to code for situations we don't yet need, but a customer could have a reusability story." Basically, the question is where does "reuse" fit in with the core computer science notions of necessary and sufficient? IMHO, the missing key is the notion of slack. Is there enough slack in the system to allow it to function reliably and robustly in the face of change? Most developers are exposed to this notion in practice in dealing with performance but slack is crucial in all aspects of software. To continue with Dan's food analogy, the orphaned code wiki, for example, is akin to putting leftovers in the freezer.

Big thanks to Dan for his tireless efforts in making the world a better place.

The Tar Pit of Programming

Frederick P. Brooks, Jr.'s classic, The Mythical Man-Month: Essays on Software Engineering is the first selection for the java.net bookclub.

I'm honored to be the moderator for this first bookclub foray and I expect things to get boiling as we attempt to address the tar pits in which we are stuck. I hope that you will join us in examining and discussing the fads, fallacies, dreams, and harsh realities of modern sofware development.

XWork v1.0 and WebWork v2.0 released

Version 1.0 of the XWork command processing framework and version 2.0 of the WebWork web application framework (which is built on top of XWork) have been released.

Talibanism in Technology?

Deepa Kandaswamy articulates his "seven reasons why women in technology remain invisible..." in Talibanism in Technology.

What do you think? Aside from the sensationalistic title, is there really a problem? If so, what's the process by which to address it?

Deconstructing the Cmabirgde Uinervtisy Rschereach Sramlcbe

Check out my Artima blog entry, Deconstructing the Cmabirgde Uinervtisy Rschereach Sramlcbe, wherein the wild meme:

Aoccdrnig to a rscheearch at Cmabrigde Uinervtisy, it deosn't mttaer in waht oredr the ltteers in a wrod are, the olny iprmoetnt tihng is taht the frist and lsat ltteer be at the rghit pclae. The rset can be a toatl mses and you can sitll raed it wouthit porbelm. Tihs is bcuseae the huamn mnid deos not raed ervey lteter by istlef, but the wrod as a wlohe.

is discussed.

Killing the Servlets, softly, with his song...

Greg Wilkins, creator of the open-source Jetty servlet engine, spouts off in his blog about why he thinks that Servlets must DIE! Slowly!!

It's hard to argue that the servlet specification isn't full of cruft and that the servlet expert group of the JCP should take a major refactoring approach for the 3.0 version of the Servlets specification. However, does Greg's notion of "Contentlets" make sense for the Servlet specification?

Two on Exceptions

Here are a couple of recent articles with recommendations of Java exception handling practices...

From onjava.com, Gunjan Doshi gives us his Best Practices for Exception Handling.

From java.net, Jim Cushing gives us hisThree Rules for Effective Exception Handling. The questions of what, where, and why are spot on.

The Poetry of Programming

The Poetry of Programming is an interview with coding poet (or "poetic coder"?) Richard Gabriel. Check it out.

Dating Design Patterns

Check out Dating Design Patterns for a refreshing take on just how powerful and useful patterns can be.

Are debuggers a wasteful timesink?

Bob Martin starts a raucous discussion when he states that Debuggers are wasteful Timesinks.

To paraphrase a character from the last Matrix movie... Debuggers are just a tool. It is how the tool is used that is good or bad.

Architecture: Abstract vs. Manifest

Some seemingly random thoughts struck me as I read Satya Komatineni's blog Architecture is language agnostic...:

No offense but... Architecture is only agnostic in the abstract. Architecture must be made manifest through language. In the particular discussion of C# and Java, both languages are so similar that manifesting architecture through them is basically equivalent. Try expressing the same architecture via Haskell or Scheme.

Declarative programming is NOT a silver bullet (to reuse or anything else). Whether the language is declarative or not (or functional or imperative or a hybrid or...), the language presents a worldview in which the programs expressed by that language may affect the world. In other words, declarative languages (such as Ant's XML-based buildfiles) (and their concomittant worldviews) are not, a priori, any more reusable than any other languages. There's always a balance to be struck between the implicit and the explicit facets.

Enforcing Model-View Separation in Template Engines

Terence Parr, creator of ANTLR, writes on why Enforcing Model-View Separation in Template Engines is a Good Thing(tm).

Ter created an implemention expressing this separation, StringTemplate Template Engine, which he's used to build a number of web sites, including jGuru.

Scheduling Snafu

Yes indeed, you know the cluetrain has left the station when perennial favorite, Doug Lea, has his Concurrency talk scheduled in one of the tiny session rooms. Yeah, that makes a lot of sense at a developer conference.

The best suggestion that I heard to help make up for it would be to make Doug's talk available online for free -- instead of having to fork out $40 (on top of the conference fee!) to be able to get access to all of the conferences sessions online.

This work is licensed under a Creative Commons License.