Everybody Hates the Popular Kid

Via Patrick, I just read Steve's latest blog post about code complexity. I think the vast majority of Steve's points are spot-on. Complexity in a codebase ultimately leads to disproportionate support and maintenance costs, complexity when on-boarding new developers, and a general productivity hit. When it takes me 30 minutes to get "in the zone", all it takes is one call from the boss to tear that down. That's a 60-minute productivity hit for a benign interruption and no tooling in the world will help you keep it all in programmer "RAM".

I was talking with a colleague of mine about this (Alok Singh) and we both agree that certain levels of complexity simply extend beyond the limits of most people's cognitive skills, it's simple and complicated all in one.

I agree with many of Steve's core assertions in this piece. But, I can't quite get past the Java-bashing and stereotyping that permeates the post and seems en vouge these days. Yes, there are bad java programmers out there, but is he really hitting on the limitations of the Java language and/or Java programmers in general?

A couple of things that stuck out for me:

"Design Patterns are programmers, and only programmers who use certain languages. Perl programmers were, by and large, not very impressed with Design Patterns."

I'm not sure I see this as an endorsement. I don't really know any non-Perl programmers who find another programmer's Perl easy to maintain. I've written a decent amount of it, and two of the top ten most miserable experiences in my programming career have been trying to decipher CPAN modules. Terse code does not make for manageable code and Perl programmers tend to pride themselves on brevity, readability be damned.

"It's obvious now, though, isn't it? A design pattern isn't a feature. A Factory isn't a feature, nor is a Delegate nor a Proxy nor a Bridge."

I don't really know what Steve's background was prior to Google, but I can say that as someone who works on commercial software which is regularly extended, our customers do actually think that having a factory is a feature. If we swap out authentication mechanisms, customers extending or writing plugins want to use a factory - they want one way to access a single API in Java. Lots of them. We could say, "no, use the REST API" but that hasn't actually seen much uptake (although it's there) and quite simply doesn't scale for core functionality like authentication.

Next is:

"Dependency Injection is an amazingly elaborate infrastructure for making Java more dynamic in certain ways that are intrinsic to higher-level languages. And – you guessed it – DI makes your Java code base bigger."

Actually, I can't see how this could possibly be correct so I'd love to hear more detail. IoC approaches like Spring reduce my code because I'm not using those design patterns that Steve is so against. I don't really care about creational logic any more because the reference I need is injected for me. I don't see Singletons or Factories any more, just references. I may have more configuration files than I did before, but I certainly have less code. Mature libraries like Spring do other nice things for me like hiding unnecessary unchecked exception handling, transactions across multiple resources and making an object remote when it has no inherent remote-ness. For example, I can publish any interface across Hessian, Burlap, JMX or RMI using spring configuration, the code doesn't know the difference. IoC has its issues to be sure, but code bloat is not one of them.

Moving on:

"I recently had the opportunity to watch a self-professed Java programmer give a presentation in which one slide listed Problems... The #1 problem he listed was code size: his system has millions of lines of code."

Ok, so the guy is a bad programmer, or he is bad programmer by virtue of being a Java programmer? I don't see the correlation. If he were giving a talk on VB would this even make the blog rounds? There are lots of bad programmers out there, but I feel like there is a real tendency to use guilt by association against the Java community. At the end of the day, one thing that is generally not disputable is that aside from the core *nix and C library collection, Java is *the* most ubiquitous set of libraries available. Steve likely has the ability to write a native hook against a native C library, I quite simply don't have the time and the Java libraries are my second-best resource.

As a counter-point, I looked at the amount of code in the mainline stable Linux kernel (2.6.23.12), which by count runs at 768119 in just the C - no headers, macros, etc. That's pretty big, and if you look at the committers, there are hundreds of people and companies (but not the almighty Google I might add) contributing towards that code base. But, for the life of me, I can't find a blog post slamming the amount of code in the Linux kernel or that it's too complex, or that it isn't contributing towards the greater good. Similarly, Apache HTTPD core seems to be running over 250K for just the HTTPD C code and surely requires a more skilled developer pool than your average Java developer would fill.

At the end of the day, I don't think Java is a programming panacea. But, if I put on my agile hat, and see that customers want solutions that they can run in their existing environments without worrying abut low-level library dependencies, and reuse a crazy amount of existing code, and that they can hire decent programmers to fulfill, then Java meets those tests and might actually be the simplest solution that delivers business value. C might be faster, Perl more "cool", but neither necessarily makes the most business sense. Business value isn't just about what the technology Illuminati tip their hat to. It's grounded in accessibility and more importantly, can I hire people to implement and support it. In that sense, Java is a decent solution these days. I tend to think business viability is a decent measure of a language, regardless of how it got there.