John Reynolds's Blog

November 2005 Archives

"I Agree" or "Cancel": We need more options

The recent Sony BMC rootkit fiasco confirms a sad fact... a digital certificate doesn't guarantee much of anything.

I don't want to delve into motivations or liabilities, but I do want to examine a basic question that technologists must address:

How can we protect computing environments from hostile executable content?

Who would dream that a consumer oriented operating system would grant a "normal" user the power to so casually corrupt the OS itself?

Is the answer an OS with a pervasive and more sophisticated Java Sandbox?

Perhaps all software that is installed on a computer should go through a probationary period. During that time, access to the file system, system registry, etc. would be tightly controlled. Data transfers to the external world would be monitored for suspiscious activity... For example, in the Sony BMC case it might be legitimate to "phone home" the name of the CD track you played most often, but there's no reason for it to phone home your bank statement.

With the flood of information and interaction between our personal workstations and the global network, it is hard to envision a mere mortal effectively monitoring traffic to and from their own devices. Hard to envision... but possible? There are a lot of really bright people out there who might figure out a way to make it practical.

Often as I wander through my house in the dead of night, heading to the kitchen for a glass of water or to get a snack, I pause to marvel at the rapidly blinking lights on my cable modem. Somebody somewhere is furiously interacting with my computer... sparks are flying off my firewall, and the "Task Manager" shows no signs of activity... but I wonder: Is all well? Is "my" machine really still mine?

This is obviously not purely an issue of technology, but surely we do have a role to play in crafting solutions.

Is Java the wrong language for business programming?

Business needs applications that can be maintained long after the original coder is gone. Java is a great language, but does Java's richness lead to unmaintainable code?

This thought was prompted by a discussion with my colleague, Jim, who has managed large projects for many state agencies over many years. To paraphrase his statement a bit:

"COBOL programmers are interchangeable, Java programmers aren't"

This comment was made in the context of an effort to migrate legacy COBOL and Java applications to an enterprise-wide Service Oriented Architecture. Should we implement all future services in Java, or is COBOL still a viable option?

Jim is not a luddite, but he is tenaciously pragmatic. In his experience in managing large projects, he has found that any competent COBOL developer can maintain another programmer's code, but Java modules are often inextricably tied to their authors. Despite coding practices and design reviews, the Java modules take on the personalities of their owners. The nuance of each Java programmer seeps into the code that they produce.

You can write bad code in any language. You can write good code in any language. Is Jim's observation about Java and COBOL valid beyond his own personal experience?

I can't confirm that COBOL code is easy to inherit, but I can confirm that Java and C++ code is more difficult to inherit than assembly language**. When a language is tightly constrained, you tend to write code like everybody else. Is increased freedom leading to unmaintainable code?

Clarification: My comment about assembly language has caused a lot of confusion among some readers... I'm not suggesting that assembly language is appropriate for business programs, or that it's easier to write or maintain assembler than Java. I've just witnessed more variation in the programming styles of Java developers than in that of assembly language programmers.

Phil Murphy of Forrester Research recently dove into the issue of maintaining applications in his report:Java, COBOL, And Perl Share A Common Problem.

The report is not free to share, but the abstract sums it up:

"The wholesale loss of application knowledge creates most of the maintenance issues, whether the applications are written in Java, Perl, or COBOL."

Phil's telling us that the primary culprit of unmaintainable applications is the loss of knowledge about how those applications do what they are supposed to do, not the language that they are written in.

Let's try to rationalize Phil's findings with Jim's observation and see what we can come up with: COBOL is not a language that encourages abstraction. Java relishes abstraction.

It is relatively easy to inherit COBOL because what you see is what you get. Perhaps a boring narrative, but it has the advantage of leaving nothing to the imagination.

It is relatively hard to inherit Java because you have to comprehend the abstraction. It is like trying to explain a concept by using an analogy. If your listener shares your cultural background, an analogy can open the doors to greater insight. If your listener doesn't get the analogy, you may have slammed the doors to understanding shut. The wrong abstraction choices can destroy code maintainability.

"The problem" with maintaining Java code sometimes comes from "abstracting away" the business process and the business logic. We often use Java to write engines that execute business logic, not to write the business logic itself. In this model, the business logic itself is scattered across numerous configuration files (often written in some custom XML-ish dialects of our own design). Although in some ways an elegant approach, this coding style can be a real maintenance nightmare if executed poorly. If you can't step through the business logic in a debugger, then you probably haven't written a maintainable business application.

Back to my original question: "Is Java the wrong language for business programming?"

The answer is in how you use the language, not in the language itself.

Solutions for the 3rd world that might make the 1st world jealous

Bruce suggested (in essence) that a really cool mobile phone/PDA is more interesting than a $100 PC. This observation prompted Felipe Gaucho to reply:

"don´t forget about the third world... The $100 PC is a revolution in countries where expensive computers are not accessible for the most of the people. $100 PC is not only a tech stuff but it is also a social improvement in many places in the world. with "Java inside" of course :)"

If we take that statistic into account and factor in Bruce's observations, then I think our goal is clearly not to get $100 PCs distributed throughout the 3rd world. If your choice was between a PC and a phone, which would you choose?

We should kill two birds with one stone, and figure out how to distribute something like a $100 version of Nokia's internet appliance, but use WiMax instead of WiFi. Add to this one WiMax access point per village, an appropriate browser-based application suite (and a willing application service provider), and I think you'll have a pretty good solution for both a cheap PC and a phone (via voice-over-IP).

If something like that was available in Kathmandu (but not here in Austin), I know I'd be jealous.

Continue Reading...

This work is licensed under a Creative Commons License.