lesscode.org

Jason Hunter (Jason Hunter), a renowned Java evangelist an the author of two highly popular books on J2EE technology (Java Servlet Programming, and Java Enterprise Best Practices, ) posted an interesting blog entry last week: The Innovator’s Dilemma: It’s Happening To Java. The “innovator’s dilemma” that Jason is talking about is expressed as follows: “you can listen to customers, provide them with what they want, but still lose out – because a cheaper, not-as-good but good-enough competitor comes in and eats your market.”

Kind of reminds me of the days when I was shopping for my home audio system. I used to visit lots of high-end shops, where knowledgeable sales personnel would engage me in detailed demos of various components, but at the end of the day I would walk across the street to some of those cheap outlets (Circuit City etc.) to see if I could get same or similar components for less.

The dilemma Jason is referring to is specifically related to Java. Here we have an exorbitantly expensive platform, that, ten years after its launch, had reached a point where it is too complex to be able to be used in any meaningful, let alone feasible fashion. So, in a way, we could say that the situation is similar to what was happening to the mainframes 15 - 20 years ago, when the businesses reached the end of their rope and realized that they need to adopt a more disruptive technology.

Jason’s thesis is that Ruby on Rails is this disruptive technology. Java is now being perceived as a sitting duck, similar to how mainframes were the sitting ducks of the early nineties. And similar to how client/server technology came about and claimed the market share traditionally reserved for the mainframes, RoR is today poised to eat into the Java’s market share (hence the ‘disruptive’ epithet).

One of the strongest arguments he makes about RoR’s threat is this one: “In programming these days, cheaper isn’t about price, it’s about mental effort.”

Now, anyone who’s ever tried to develop a web application using the J2EE frameworks, and then tried to to the same thing using RoR, will undoubtedly agree that RoR requires significantly less of a mental effort. And thus, RoR is significantly cheaper.

Ironically, it was this same quality that made Java so attractive 10 years ago. Due to the fact that Java was so much simpler than C++ (so much so that in its early days Java used to be called ‘C minus-minus’), it made huge inroads into the development community’s mind share, and overtook C++ as the language of choice when it comes to developing applications. Lowering the cost of software development is obviously a strong driving force in motivating the adoption of the new technology.

The mood in the Java camp nowadays is really strange. As is to be expected, the prevailing sentiment is the one of huge denial. This is similar to the mainframe crowd sentiment 15 years ago.

But the odd thing is that the same people who tend to shrug off RoR’s threat to Java seem to be at the same time working frantically on proving that Java can be concise too. Ironically, they are attempting to introduce simplicity into the Java platform by adding new features to it! This leaves an open question: since when is bloat to be regarded as simplification?

In the final analysis, it is extremely significant that a number of top-echelon Java evangelists are jumping into RoR heads first, and are buying into it hook, line and sinker. The worrisome aspect of all this is that, once RoR takes off and hits the mainstream, who’s going to do the new development? Most of the existing development workforce hadn’t managed yet to make the transition from procedural to object-based approach. The full fledged OO nature of Ruby, coupled with its dynamic nature, may prove to be too big of a challenge for the average application developer out there.

I’m indebted to Ryan for bringing Clay Shirky’s online catalog of articles to my attention. While reading Clay’s “Semantic Web, Syllogism, and Worldview” article (a totally smashing, almost to the point of being devastating piece of writing, by the way!), I almost jumped out of my chair when I ran into the “this will work because it will be good if it did” fallacy. Yes, the field of software is littered with these kinds of fallacies.

Take the myth of the code reuse, for example. It is clearly one such fallacy – “it would be nice if we didn’t have to expend any effort in creating software code, and so reusing existing code will work.” And because everybody nowadays seems to adhere to the code reuse fallacy, the state of the software industry is nothing short of dismal.

Now, me being the most rabid, foaming at the mouth less-code evangelist, you would expect me to automatically be a huge reuse champion. However, I’m not. How can that be?

The explanation is very simple: I’m not sure I understand what reuse is. You see, instead of glossing over the meaning of the word and simply riffing on it like most other software people seem to be doing, I have this nasty habit of looking deeply into the meaning of the word, before I hang up a shingle with that word proudly displayed on it (like, a hypothetical “Alex’s Reuse Shop”, for example).

So, I always tend to go for the easiest angle, and look into the real world, common-sense examples first. What is the meaning of reuse in my everyday affairs? OK, the first thing that comes to mind is my chair. I was using this chair yesterday, then I left it at the office and went home. Today, I came back into the office and started reusing this chair.

But wait. In common parlance, this is not how we speak. I’m not reusing this chair, I am merely using it. And I’m doing it over and over again. But notice how despite the repeatability and the predictability, it still doesn’t qualify as being reused.

Am I today reusing my kidneys and my lungs, or merely using them? I know this may sound overly pedantic at a first glance, but it is very important to make this distinction.

Similarly, if I drop a calendar control into my app, am I reusing that piece of code, or using it?

I was using Microsoft Word application to produce a document yesterday. I liked the experience, so today I’m again at it, typing up this document. Am I at this point reusing Microsoft Word?

My intuition is telling me that in all those cases, I am merely using objects and concepts that become available in my daily existence. I’ve never been, so far, in the situation where I was reusing anything.

So the question is: why should my activity of software development all of a sudden be completely centered on some phantom, piss-poorly articulated concept of wishy-washy reuse? Why should I force myself to think that the code I’m writing right now must be able to be reused later on? Is there a real justification for such a taxing burden that’s been thrown upon our meager shoulders?

Why not, instead, simply focus on the task at hand? Try and solve this concrete task that is before me the best I can, without worrying about whether my design will be a good candidate for some whimsical concept of reuse.

As I’ve explained in my previous article, when I’m developing my PowerPoint presentation, I never think of reuse. Never do I stop and think “hey, but what if later on I, or someone I don’t even know, whish to reuse this slide, or this portion of the slide, or this group or cluster of slides?” I could never get bothered by such concerns, and so my mind is free to fully concentrate on delivering the highest possible quality of presentation.

Same is with any other activity. If I engage in explaining to the customer how will our approach benefit them better than IBM’s WebSphere portal approach, I never stop and think whether all or some parts of my present activity will be reusable in the future. I just concentrate on doing the best possible job, and then move on.

Software development should be the same. Shed off any extra taxing burden of worrying about the future that never comes, stop asking yourself “what would ‘…’ (enter the name of your software guru de jour here) do”, and simply do the thing that you’re good at doing.

I guarantee you that you will produce much higher quality code that way.

I was recently hired to deliver a presentation on the Goal Oriented Software Design. The added twist to the challenge was that the presentation was supposed to be narrowly tailored to the client’s business domain, with some concrete examples. That meant that I couldn’t get away with just a generic presentation – I had to invest some serious time in research, before I was able to even think cogently about the specific problem.

The paying client was clear about that requirement, and was happy to oblige me. Not before asking me for the estimate, though, which ended up in thousands of dollars. Having no particular objections to my estimate, the client signed the SOW, and I went off to merrily prepare the presentation.

But then that episode got me thinking. Here we have a budget-conscious company, signing a hefty invoice in order to consume the presentation that basically got delivered to them within one hour (that’s all it took for me to run through my slides and to fend the QA period). That presentation was a one-time event, a throwaway, if you will.

Now, imagine if, instead of negotiating for a presentation, I was involved in negotiating the delivery of a software application with the same company. Would I be able to get away with thousands of dollars invoice for delivering a throwaway application that would only address a very narrow and specific problem domain and that only for a very short period of time?

The answer is, of course, a resounding ‘no way!’ No one in their right mind would ever approve building an application that would be useful only to several people, and only for a couple of hours/days.

But really, what’s the difference between such an application, and the presentation that I’ve delivered? My presentation, while doubtlessly viewed as being quite useful to several expert users within that company, was valid only for an hour or so. The fact that it took me more than two weeks to prepare something that will have useful lifespan of only an hour or so apparently didn’t seem to bother anyone. A software application, on the other hand, gets invariably perceived as being something that not only must possess phenomenal longevity (at least 3 to 5 years, according to the current rule of a thumb), but must also offer a huge portion of salvageability, that is, reusability.

A typical business presentation, such as the one delivered using Microsoft PowerPoint, is not expected to be reusable. In truth, however, there usually is quite a wealth of useful information and knowledge buried inside such typical presentations. But no one seems particularly bent on salvaging that content, or on reusing it, or on evolving it, etc.

But as soon as we step into the world of software application development, the delivered source code, and all the embedded knowledge it carries within, gets treated as pure gold. All of a sudden, everybody starts hyperventilating about the ability to reuse it, not to reinvent the wheel, yadda, yadda, yadda.

I must admit at this point that I’m a bit mystified as to why would one kind of knowledge (i.e. the knowledge embedded within software source code) be so extremely precious, while another kind of knowledge (i.e. the knowledge embedded within other business documents) be viewed as easily reproducible and thus not worthy of extreme ritualization. Especially when often times the two apparently different kinds of knowledges turn out to be quite similar in scope and in intent.

Something is terribly mystified (beyond any recognition) in the world of software application development. If someone is prepared to spend several thousands of dollars on articulating and communicating certain valuable, albeit disposable message to the targeted narrow audience without even batting an eyelash, yet at the same time balks at similarly useful articulation of the equally important knowledge to be delivered via the software application code, that tells me that something went haywire along the way. Reality check is in order.

On the flip side, however, I had to ask myself how is it that I feel perfectly comfortable delivering all those disposable PowerPoint presentation without ever looking back, and yet at the same time I find myself striving to build the software code that would be as general-purpose as is humanly possible? Am I being reasonable in behaving that way?

If someone asked me to deliver a PowerPoint presentation outlining the optimal strategy for building a teacher’s grade book that would collect assignments and quiz marks and grades and summarize them into the final grades, I would gladly jump to the challenge and quite comfortably ask for 5 to 7 days of research time. I would be quite certain that I could deliver a high quality product in that time frame, starting from a completely clean slate.

However, if they asked me to deliver the application code that would allow teachers to collect all the grades and summarize them for the current grading period, according to the particular rules that the school in question operates under, I would be reluctant to jump at it and commit to delivering it within the 5 to 7 days time frame.

Why, what is different with the software code compared to the PowerPoint content? Basically, the fact that both current technologies in vogue, (both Coke and Pepsi, that is, J2EE and .NET) are so complicated, prevent me from feeling comfortable in delivering a highly customized solution.

But, realistically speaking, I think it is becoming more and more clear that delivering huge, bulky, all-things-to-all-people software applications is simply not the way to go. We are now ushering into an era of disposable software. Build it quickly, with a particular narrow problem in mind, and for a particular, possibly short time frame of valid use. Then, be prepared to throw it away, and to move on, not looking back.

Up until recently, such a thing would sound more like science fiction, but today, thanks to the new generation of tools and new outlook on the philosophy of software development, such an approach is becoming increasingly feasible. I will give a brief illustration here:

Last year I worked on a project that aimed at delivering administrative functionality to the school districts throughout the North America. The project was conceived and driven by a high tech company, itself driven by various high tech concerns and agendas. Thus, we ended up with the ungodly mixture of .NET, J2EE, and a bit of the Oracle technology thrown in for good measure.

But the real problem was in the lack of true focus. The product was being built with a vague, generic individual user in mind. Thus, most of the features that the product offered were completely amiss. And because the end-user acceptance was so poor, the all-knowing higher-up powers started driving even harder towards generalization and future flexibility. Which means, when translated to dollar value, that the application was exorbitantly expensive to design, develop and maintain.

Because of that, it was put up on a pedestal, and was treated like a sacred cow in all ways imaginable.

Anyone who would dare suggest that, instead of attempting to build one giant, general purpose app, we focus on building several more specific apps that would address specific needs of individual districts (or even schools), would be shunned, ridiculed, and eventually thrown out of the boardroom.

Thus, we’ve ended with an extremely precious product that had myriad of features that end-users mostly didn’t care about. But, the final product is now exorbitantly expensive. Would anyone dare, at that point, tell the powers that be that such a product should be just a throwaway? Not a chance in hell! And so the dance of deception continues.

Meanwhile, all that the targeted segment of end-users wants is a simple app to allow them to do their job easily. And they are not thinking in terms of many decades of blissful use. Just let them do the specific job right now, for this specific event (such as submission of final grades).

In reality, a good software developer should be able to do just that – deliver a disposable, short lived product that addresses only the pressing needs of the moment, and then simply disappears. No maintenance, no enhancements, no song-and-dance, nothing. Similar to how my one-time business presentation required nothing more but to simply be consumed, and then thrown away. No fuss, no muss.

Sam Newman has a fairly thorough comparison of Django and Rails over at magpiebrain.com. He compares the following traits of the frameworks: language, requirements and installation, deployment options, caching, project setup, adding models, interaction with the database, projects and applications, controllers and URLs, templating options, and administration / user management.

It’s a nice comparison, although the concluding section on choosing a framework seems to be getting some flak:

If you are developing a simple (in a domain model sense) application where you want to use Ajax to deliver a great UI, Rails is probably for you. If however you want to develop an entire site with different types of applications within it - then Django’s plugable applications and general approach might be what you’re after. Equally, the better user and administration side of Django favours portal style applications – this is something you’ll have to do yourself if you want to use Rails.

Rails is, of course, not limited to AJAX-heavy apps with simple domain models. I’m assuming Sam didn’t mean to give that impression but was just trying to wrap up a long article quickly. Perhaps he’ll clarify a bit.

Django committer, Jacob Kaplan-Moss, followed up with some thoughts on the post.

As a side note, I had planned to do a series around this but I promised Adrian and Jacob I’d hold off until Django was launched-launched, which I assumed meant 1.0 at the time but that seems a ways off now… I’m not sure Django can get any more launched at this point so I might have to revisit that promise as I’m anxious to get moving on this.

Excellent press over at news.com today featuring many a friend of lesscode.org. Martin LaMonica’s From Web page to Web platform barely scratches the surface of potential we’re uncovering with the web but it’s enough.

There’s the mandatory O’Grady quote:

Instead of treating the Web just as a handy way to publish information, businesses need to start acting like software companies and encourage programmers to build services on top of their platforms, analysts say.

“The conclusion that many savvy Web presences had is very similar to what software companies have realized with open source: As creative as your organization may be, the community at large will always be more creative,” RedMonk analyst Stephen O’Grady said.

Adrian Holovaty’s chicagocrime gets a mention as well:

Allowing individuals to play with their Web site data has resulted in programs that the companies might never have thought of. For example, Adrian Holovaty, a 24-year-old programmer, built a Web site called Chicagocrime.org that taps into Google Maps to display where crimes occur in Chicago.

I picked up the link from Mark Baker, who comments:

As I’ve said before; Web services? You’re soaking in them!

Indeed.

I’d also like to mention that this article was posted to the Enterprise Software >> Web Services section of news.com, which is exactly where it should be.

I’ve nothing to bitch about today people, sorry.