John D. Mitchell's Blog

Programming 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!

JaveOne 2007, Enterprise Search-Driven Developement

One of the most exciting things at the show this year is that my company, Krugle, announced the beta of an enterprise search appliance for development teams.

After all the months of labor, I can finally share our little bundle of joy with the world. :-)

In my experience, one of the biggest problems that enterprise developers face every day is finding useful information across the bazillion different silos of information that we have to deal with just to be able to work on our projects. Specifications, design docs, source code, issue trackers, mailing lists, notes, blogs, wikis, souce code control systems.... Mixing in time-to-market pressures, cost reduction, reuse goals, agile methodologies, and the like pushes us to a just in time way of life.

Finding relevant information amid that chaos is all too often painful and labor intensive. So, the core feature of the Krugle Enterprise appliance is to pull all of those silos together and make information available via search. This search-driven development approach is how development teams really work these days -- developers looking for example code, QA looking for bug fixes, maintainers trying to figure out the impact of making a change, managers looking at risk indicators, etc. -- we're bringing it all together.

Of course, I'm totally biased so ignore my blathering and check it out for yourself and your team.

JaveOne 2007, Java Puzzlers Points Out Problems with Kitchen Sink

Josh Bloch and Neal Gafter have been doing their wonderful Java Puzzlers shtick at JavaOne for the last 4 years. This year, Bill Pugh has stepped in for Neal to keep the puzzlers puzzling.

The puzzles point out all sorts of interesting and exasperating gotchas in the Java language and libraries that linger for ages waiting to humble us all.

This year's set of puzzles include a slew of problems that come as a direct result of the addition of auto-boxing/-unboxing of primitives to/from their object wrapper types (int and Integer, for example). Maybe it's just me but I seem to recall a lot of us who said how bad the consequences would be of adding auto-boxing to Java and yet here they are causing exactly the worst kinds of insidiously non-obvious problems.

The moral of these puzzles isn't merely "be careful of using wrapper types with the ternary operator", but that auto-boxing is evil and should have never been added to the language in the first place.

Of course, it goes without saying that this is just one example of how new "features" added to a mature language are very dangerous. One of the big, currently brewing brouhahas is over the proposed addition of closures to Java. Perhaps folks might want to pause their rampant fervor for a bit and actually look at the history of these attempts and realize just how costly these changes really are. Especially when there are plenty of alternatives like using other languages which have their pet features which target the underlying JVM.

As Josh so eloquently put, "APIs, like diamonds, are forever."

Krugle is hiring

Yes, it's true that I've been lax in my blogging so far this year because I've been working as the Chief Architect of Krugle. Sure, I've written some entries on the Krugle blog but living the startup life is definitely not conducive to regular blogging -- even at a company whose blogmaster is none other than the wild and crazy Chris Locke of e.g., The Cluetrain Manifesto fame (and the rest of the team ain't too shabby, either :-).

What we're creating with Krugle is a search engine for software developers. I.e., no more pawing through pages and pages of Google searches, hunting around various web sites, etc. trying to find useful results for technical information. We're crawling millions of technical pages and sucking down terabytes of source code using Nutch, processing pages with Antlr-based parsers, and serving up the search results using Lucene.

The site is currently in a limited beta and we're getting great feedback. I just saw that we're the most anticipated launch on the Museum of Modern Betas. Heck, that's even cooler than winning a DEMOGod award.

So, if you know any take-no-prisoners, hardcore people who want to work on a project that's actually making developers' lives better... Krugle is hiring.

Tests, Specifications, Typing, Oh my!

There's some interesting discussions taking place on the nature of tests. Brian Marick distinguishes between tests as specification vs. tests as examples. Michael Feathers asks if type systems in programming languages are really tests.

Kevin Lawrence (and the Agitar crew) talk about the philosophical contention between the notions of For All and There Exists. That is, the difference in mindset of existentialists vs. universalists. Looking at debates in e.g., the extreme programming world, there's a lot of confusion and arguments back and forth that stem from this constructivist vs. deconstructivist conflict.

The biggest tragedy in these debates, IMHO, is that people on both sides of the fence polarize and calcify in their self-righteous positions. The fact is that we need some amount of both approaches to succeed. For example, writing test-first leads to horrible code if you don't also refactor as you go. Accretive unit tests that aren't themselves refactored leads to big, ugly and unmaintainable test suites. More simply, positivist (aka "garden path") tests must be balanced with deconstructivst (test (to) destruction) tests.

Stepping up a level or three, it's even better if, rather than merely mitigating and ameliorating problems, we change the game such that it's hard/impossible to even articulate bad ways and trivial/easy to articulate the garden paths. That is one of the biggest benefits to taking a linguistic approach to development.

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.

Code Naked

Finding yourself naked, in public, is a dream/nightmare that many people have. It could just be me but when I was first starting to program, I had a nightmare that not only was I coding naked but my code was naked, too. Partly in response to that, I became much more diligent about writing excellent code so that I'd never be embarrassed by my software.

Over the years, I've joked with various people that I "code naked" but most folks stop at the (all too frightening) image of me coding while naked. Alas, I've never thought about a more palatable phrase enough to come up with anything worth mentioning. Various industries like to use the term transparency but methinks that's too opaque and wishy-washy.

A student of Bob Koss comes to the rescue with the term Refrigerator Code:

It's code that you’re so proud of that you want to take it home and hang it on the refrigerator, right alongside of your children’s drawings.

On the other hand, one of the underlying reasons of Why Software Sucks is the fact that most software written is really what I call Toilet Code:

It's code that's so mediocre that when somebody encounters it, they just want to flush it down the toilet.

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.

What does 99.999% reliability really mean?

Michael Levin posted a Java coding challenge this morning to write a Java program to show what terms like e.g., 99.999% reliability actually means.

Here's my quick and dirty take (written while watching F1 :-):

/*
 * What does X nines reliability really mean?
 */

import java.io.*;

public class Nines
{
    private static int SPM = 60;
    private static int SPH = SPM * 60;
    private static int SPD = SPH * 24;
    private static int SPY = SPD * 365;

    public static void main (String[] args)
	{
	spit ("Nines of Reliability: (Hours / Minutes / Seconds)\n");
	spit (2, SPY / 100.0);
	spit (3, SPY / 1000.0);
	spit (4, SPY / 10000.0);
	spit (5, SPY / 100000.0);
	spit (6, SPY / 1000000.0);
	spit (7, SPY / 10000000.0);
	}
	
    private static void spit (int numNines, double seconds)
	{
	spit (numNines + " 9's (");
	for (int i = 0; i < numNines; i++)
	    {
	    if (2 == i)
		spit (".");
	    spit ("9");
	    }
	spit ("%) = up to ");
	spit ((seconds / SPH) + "h / ");
	spit ((seconds / SPM) + "m / ");
	spit (seconds + " seconds of downtime per year.\n");
	}
	
    private static void spit (String str)
	{
	System.out.print (str);
	}
}

Which tells us:

Nines of Reliability: (Hours / Minutes / Seconds)
2 9's (99%) = up to 87.6h / 5256.0m / 315360.0 seconds of downtime per year.
3 9's (99.9%) = up to 8.76h / 525.6m / 31536.0 seconds of downtime per year.
4 9's (99.99%) = up to 0.876h / 52.559999999999995m / 3153.6 seconds of downtime per year.
5 9's (99.999%) = up to 0.0876h / 5.256m / 315.36 seconds of downtime per year.
6 9's (99.9999%) = up to 0.00876h / 0.5256000000000001m / 31.536 seconds of downtime per year.
7 9's (99.99999%) = up to 8.76E-4h / 0.05256m / 3.1536 seconds of downtime per year.

So, 5 9's means less than 5 1/2 minutes of downtime per year. Hmm... Now, how long does it take your server just to boot once?

Communicating Conundrum

Kim Burchett posted a great story illustrating the Misunderstandings that happen in the software business. Hilarious, in a sad, scary, and all too true way.

Steele Fortress

Guy Steele is leading a group to build a new programming language called Fortress. In homage to the old SATs, Fortress is to Fortran as Java is to C++. :-) That is, Fortress is about doing high-performance number crunching. Alas, Fortress is not yet available for us to play with. The complete article is: The Soul of a New Programming Language.

The most telling quote:

"I'm now not convinced that a single programming language can serve everyone's needs, because the needs are so diverse." —Guy Steele

Belief of Control

Well, I am a sucker for discussions about risk and software development. There are some interesting tidbits in Tiwana and Keil's: the one-minute risk assessment tool article for the ACM's Queue magazine. Alas, there are some fundamental problems with the article. So, definitely read it, but with a few grains of salt :-).

First off, while they noted the (potential of) self-selection bias, that's buried in a sidebar.

In conjunction, they completely gloss over the fact that they are only dealing with the stated assessments of the participants (i.e., the upper-level managers) of these projects. That is, they miss the entire point that the stated reasons rarely coincide with the real reasons.

In addition, they only talked to high-level managers — where's the talk with the people actually doing the work?

Building on those mistakes, of course the outcome of the research supports the notion that the managers can exert a lot more control over the success or failure of projects. Now, you're probably nodding your head and agreeing — fine, that fits our underlying intuition but the article and those managers are making rationalizations — not revealing reality. The first problem with the rationalization is the Belief of Control. I.e., the belief that managers (and other people in positions of authority) have that they can control everything. [Though, I love the ending of the article with the paraphrase of the Alcoholics Anonymous prayer. :-)] On another hand, in the vast majority of projects, of course the managers can control the success or failure of the project — because the managers are the cause of most of the problems. That is, the managers consciously and unconsciously set things up to fail through e.g., ignorance, neuroses, politics, greed, and just plain incompetence. Even worse, as the project unfolds over time, the tendency of managers is to apply those same broken approaches to "fixing" the problem and thereby usually just make things worse.

"We have met the enemy and he is us." —Walt Kelly, Pogo

Anatomy of Insanity

CNet reports that Microsoft is offering $5 (yes, 5) for data loss due to it's new AntiSpyware software that's in beta testing. Gee, thanks. That will buy me a cup of coffee so I can calm down after you destroy my data. Yeah, sure.

This is another case of how Microsoft (and so many other organizations) just doesn't understand (or care) how enormous an impact their buggy software has on users. This goes part in parcel with the wonderful example in my old blog entry Anatomy of Insanity? Of course, they will claim that this offer is somehow helpful to the customers but, I must say, it's just plain insulting. Why not try something revolutionary like actually writing high-quality software?

Use less milk?

My little girl has this habit of pouring way too much milk into her bowl of cereal. Then, she whines and complains when we tell her to drink up the extra milk after the cereal is gone so it doesn't go to waste. Yesterday, she got quite snippy when I dared to suggest that she try pouring less milk into the bowl.

Gee, she sounds like a lot of managers and developers of software.

Though, to be more precise, in most software situations, it's not that they pour too much milk but, rather the converse: trying to eat way too much cereal for the given amount of milk. Of course, it gets even worse when we're asked to eat random weeds from the edge of the parking lot instead of cereal because the powers–that–be misheard some "guru" talking about the miraculous recuperative abilities of mountain goats who eat nothing but weeds.

In terms of software estimates, why are we, as an industry, so far off? Is it merely incompetence or perhaps fibbing to say what the suits want to hear or are there more subtle things going on, too? I think it's exactly the same problem that my little girl has... She can see the surface of a pile of cereal in her bowl and as she pours the milk, she sees the milk run off the surface and disappear, by the time she sees the milk level come up towards the surface of the cereal, it's too late.

Now, some folks might say to eat more, smaller bowls so you don't run into that milk hiding problem (which is related to the burning your mouth on the hot sauce hiding under the cool layer of cheese on your pizza :-). Others might advocate pouring some amount of milk into the bowl first and then pour the cereal to match. Anal-retentive types might do a myriad of studies (i.e., waste a lot of milk and cereal) to figure out some magical metric by which to precisely predict the proper amount of milk to use for the average cereal according to the preferences of some imaginary average person.

Me, I like an adaptive approach: Pour some cereal, pour some milk, mix it all up, and taste it. If there's too much milk, add a small amount of cereal. If there's too much cereal, pour a wee bit more milk. If it's exactly right, look for the Candid Camera folks (especially if I used up the last of the cereal and milk simultaneously :-). Gee, for some reason, this tastes the same as another process.

Bon apetit!

Successive Embellishment

Growing up, one of the things that I was taught was that embellishing was wrong. That was confusing to me since the actual definition of embellish is: "To make beautiful, as by ornamentation; decorate." Of course, my mom and various "teachers" really meant to teach me that telling lies is a Bad Thing(tm). Alas, like so many of us, precision in language isn't much of a priority — we over-rely upon the communication of our emotionalism to impart our intent.

In Spiral Learning, Kathy Sierra talks about the need to and benefits of iterating quickly through the entire cycle of learning. If I may be so bold, what she's talking about is the notion of Successive Embellishment. Basically, start small and simple and then iterate. But, rather than the traditional view of us following the spiral inward, tighter and tighter, we're going the other way: we follow the spiral outward, embellishing what we've already done — not only makes it more beautiful but also more valuable.

Your homework, should you accept it, is to connect Successive Embellishment with the notion of Passionate Curiousity.

It's about about the language

The Furious Purpose blog entry,Mock roles, not objects mentions a paper given at the last OOPSLA on how to think about mocking in terms of roles that need to be fulfilled. Partly, the blog entry is about the benefits of TDD (Test-Driven Development). If you're not hip to TDD yet, check out Kent Beck's book Test Driven Development: By Example.

In my mind, however, there's something a bit more fundamental and interesting underlying this discussion... That is, answering the question: what's the language that is being created? In the Furious Purpose example, it's a language that is manifested as a programmatic API in Java starting with a user login story. As programmers, that fact that we are creating and manipulating languages seems about as obvious as water is to a fish but that is precisely why I think it's something worth thinking about -- we are so easily caught up in the leaves that we miss the trees, the forest, and the bulldozer that is about to run us over.

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.

Is it stew, yet?

Before directing you to an essay on Language Oriented Programming, I want to make one other comment about this particular pumpkin soup. We're eating it today and yet I made it Tuesday night. I learned this at a restaurant I worked in. The chef served "yesterday's soup" instead of "the soup of the day". He said that most people know that soup always tastes better the next day so that's when he serves it. This gets to John Mitchell's Slack post. It would be nice to have the time to work ahead on some project and let it sit. You could then come back to it in a couple of days and have the fresh perspective to improve it before serving.

In XP, one of the benefits of pair programming is the difference of perspectives between the current driver and the copilot. Another refreshing perspective change comes when shifting between the two roles. One of the biggest benefits of test-driven development is the forced change in perspective as you shift back and forth between test writing and code writing.

If you're not working in a pair, you can simulate this yourself by working on a task for awhile and then put it aside and come back to it later.

Obviously, the relatively short granularities on the order of minutes are good for getting some kinds of perspective, it's critical to also sprinkle in the larger granularities of days and weeks. There's nothing like a sleep cycle or three to let your brain disengage consciously but continue percolating on it unconsciously to brew some fresh thinking.

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.

Generics Tutorial

Sun has released Gilad Bracha's Generics Tutorial.

Whitespace, The Language

Whitespace is a language whose syntax comprises only the whitespace characters space, tab, and linefeed.

Do you floss every day?

In Testing MVC actions, mock objects and code coverage, Simon Brown wonders aloud about how to think about the issue of code coverage via tests. It's quite simple really... The rationale for testing and high test-coverage rates is exactly the same as for brushing your teeth and flossing everyday.

Is Critical Thinking for Software Developers?

"Mr. Ed" deconstructs the all too common tendency of developers to make horrendously vague propositions in his Basic Critical Thinking for Software Developers blog entry.

His primary example is an assertion about pair programming so extreministas should definitely go wild. :-)

J2SE v1.5.0-alpha availability with JSR-166 updates

Rather than being forced to register at JavaLobby to be able to get access to the release, you can download the Java 2 SDK, Standard Edition v1.5.0 alpha release directly from Sun.

People interested in the JSR-166 Concurrency additions should note that the Tiger alpha release does not contain the latest version of the package. You can get the latest version from the JSR 166 resources web site.

Security State

Philip Brittan blogs about his various articles dealing with Security Strategies.

State is the second worst thing in distributed computing.
No state is the worst.
--John Ousterhout

Erik on Velocity Templating

Erik Hatcher writes Velocity: Fast Track to Templating -- a nice and quick introduction to the Apache Group's Velocity Templating engine.

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.

"Raving" Lunatics?

Dan Steinberg mentions:

Vincent's post about the dependence of Sun tools on NetBeans seems to imply why Sun is not prepared to fold or merge NetBeans into Eclipse.

when talking about Vincent Brabant's blog entry about "Project Rave" and my blog entry about NetBeans staying separate from Eclipse.

Indeed, Sun's own Rich Green has talked about Sun's concerns of that they not "abandon the constituents" (users) of NetBeans. Green also expressed his concerns over IBM's domination of the Eclipse project. Gee, that certainly makes it sound like the negotiations fell through because both sides fought about control over the merged project.

So, even with these nominally open source projects, to the people/organizations involved, it's still all about who's the boss.

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.

Why Humans Should NOT Have to Grok XML

Terence Parr, creator of ANTLR, wrote an excellent essay on why humans should not have to grok XML.

This work is licensed under a Creative Commons License.