I'm beginning to think that a long nightmare in the computer software development industry is at an end, or very close to it. The nightmare that was the Java revolution is fading fast and from my perspective, good riddance to bad rubbish. But let me not get to the punchline of this fair tale too quickly. Let me take you back to the time when the dot-com bubble was just about to burst.
I was at a startup at the time and when some of the bigger dot-com companies started to go under I was hiring new engineers. That gave me the chance to see and talk with a lot of the newly layed off engineers. It's from those interviews, and from my talks with other engineers in the Silicon Valley that I've come to understand just what happened during those years to our jobs and our profession.
My version of the story is a fairly simple one. Though I am sure many will find fault with it. It starts with the first generation of early web engineers who used whatever they had at hand to develop sites. In general that was Perl, Python or C, and later ASP. These early sites, including Amazon, fed the financial markets and innovation that spurred the "new economy" of the dot-com revolution. At that time Sun's Java technology was thought of as a toy that added interactivity to the browser. But Sun wanted entry into the server market so they published a white paper along with their first version of the JSP technology. The white paper concluded, not surprisingly, that the Java technology was far more scalable and reliable than Perl (among some others).
That term "scalable" was something that I would hear over and over again when Java was compared with any other technology. Java was "scalable" and others were not. Period. When I read that Sun white paper and noticed immediately that they were comparing apples with oranges. Their in-memory server solution was compared to Perl runnning out of process. Little wonder that the oft-cited graph showed Java beating the pants off of Perl. When the two met head to head in-memory there was little difference in speed or scalability. But the damage was done and the white paper gave ammunition to a group of new software engineers trained exclusively on Java and who chanted "Java is the one true language", along with Scott McNealy over at Sun.
The effect this had on software shops was devastating. I know more than a few early web engineers who lost their jobs because companies made the switch to Java. The engineers were labeled 'change averse' because they fought the move to Java and were given copies of "Who Moved My Cheese" as they were booted out the door.
The companies suffered too. Java server technologies in the early days were a complete disaster. Many companies found out to their detriment that the old web engineers were right, Java didn't scale, in particular EJB 1.0 was a scalability disaster of the first order. Among the many interviews I had with Java engineers at the time and since I have never heard of a EJB 1.0 web application that was written to spec that actually worked. I heard this story too often to count; "The company started with an app developed in Perl. They decided to go to Java. They fired the development staff and restarted with Java. That's where I came in. The app was never finished and about two years later the company ran out of money without ever shipping another version." Which I find almost criminal on the part of the engineers because they should have found a way to ship something with reduced functionality to keep the company from going under.
As Dylan would say, "times, they are a changin'", and so we see now that the development world has come full circle. The engineers who could pass the dreaded "Java purity test" soon crept up the management food chain (as they had always wanted) or left the business entirely. And those "change averse" web engineers can now hold their heads high when they talk about using rapid development technologies like Perl, Python, PHP or Ruby.
This isn't an all or nothing proposition. The two sides in the argument were never "Java or Anti-Java". It was always "Java or The Right Tool For the Job". Sometimes Java is the right tool for the job. And sometimes Perl is the right tool. A good engineer has a variety of tools in their toolkit and is always looking for new tools that can speed development. Lately folks like Bruce Tate and Martin Fowler, long time Java advocates, have been changing their tune, not to a particular technology, but to the "right tool for the right job". I applaud that. This is where we should have been all along.
Investors certainly learned a lot from the crash of the dot-coms. (Though not so much that they are hesitant to invest in the new web 2.0 bubble.) What did we as software engineers learn? I can't speak for us all but here are some things that I picked up from the last ten years.
- Technology choices should be based on technology reasons. Too many companies picked Java because it looked good on the prospectus, or because engineers who were interested in resume padding thought it was the right way to go.
- Hiring is everything. Successful software companies hire engineers who are curious and impassioned about technology in the large. And with that larger perspective they are able to choose the "right tool for the right job" and avoid technical disasters like the early Java web technologies. Innovation is made by those who are excited about technology and it's impact on people's lives. It's not made by those who think that programming is "just a day job".
- Companies lie. Engineers need to look critically at the white papers and technical information published by companies that have a vested interest in the adoption of that technology.
- Pragmatism. If you haven't read the "Pragmatic Programmer" you really should. The book teaches a set of skills that help engineers grow in their profession and as people. And gives them a life-long skill set that is focused on providing value to every type of customer. And those types of skills help us avoid the mistakes we have made over this past decade.
- Trust. One thing that was lacking all around in the dot-com era was trust. The upper management of companies need to trust in the software engineers and that trust needs to go both ways.
- Engineers need to learn basic communication skills. One would have thought that the success of Perl before Java would be self-evident. But such is not the case. Engineers need to understand that directors and CEOs read the Wall Street Journal and not the Perl Journal. We need to communicate at a business level to make successful technology arguments to upper management.
- Change is not always good. Despite what "Who Moved My Cheese" would have you believe, change is not always good. The risks and rewards of technology change need to be evaluated critically. And prototypes need to be developed so that risks can be properly assessed.
I'm not so young and naive to think that the type of nightmare that occurred with Java and the Java web server technology was a one time fluke. Cobol was replaced with C even though Cobol is arguably a better language for the business domain. And to a smaller degree there was a strong push with Ada that left some "change averse" programmers on the street.
But just because we have made mistakes in the past it doesn't mean that we are doomed to repeat them. If engineers learn new soft skills that create better communication and trust with upper management it's possible that this type of debacle can be avoided in the future. Or at least I hope it can. We won't know until we have the next "one true language" and we are all put to the test yet again.
(For those folks who will think this is anti-Java rant, I actually really like Java for certain jobs. I love Eclipse. And I love what Java has enabled in the way of new lightweight built on top of the JVM. Yes, I'm certain there have been Java web server success stories. But the Java web application failures are there. And we need to, with the benefit of hindsight, see what went right and what went wrong with the Java revolution. And yes, I am the guy who wrote the O'Reilly article several years ago that dared to suggest that PHP and Java are in the same league and that Java on the server was learning a thing or two from PHP.)
Dru Nelson is also thinking along these lines and got me thinking about it.
Was the Java revolution everything it was cracked up to be?
Categories
Web
Comments (21)
Read More Entries by Jack Herrington.
Well Said
You hit the nail on the head.
When 'Client-Server' was new, the industry was full of success stories. New business problems being solved, faster delivery of software solutions, and decreasing hardware costs (mainframe elimination).
The whole n-tier object oriented movement has not generated the same list of success stories, in fact, just the opposite. Many IT groups have become the 'tail wagging the dog' for their own perceived gain, rather than doing what they should do, automate and solve business problems.
stats
That is where web projects benefit from the ability to make incremental improvements. I've just spent a year making incremental improvements to dozens of sites that shipped early - some of them were pretty crufty - but all were successful (they made money for clients and the business).
You can't get the architecture completely right up front, what you can get is documentation and specs from which to build tests later on and refactor. Perl is actually very nice to refactor assuming a basic level of code quality.
The problem is when you believe the hype from Java programmers and attempt to switch. I don't think there I have seen a successful switch from a dynamic language like Perl, PHP, etc to Java pulled off - either it has been cancelled, postponed or taken the company down. Very often the switch doesn't even get started as most Java programmers don't have the knowledge of perl to move an existing perl system to java, and only in some distant fairy land would you find a company that wanted to move to Java and had the necessary specifications and documents in place, at a guess , 99% of the time the problems they blame on the perl system are due to a lack of documentation, specs and investment in staff rather than a lack of architecture.
Not Java Rant !?
After all, it is about Java. It is OnJava. :-)
I think it is positive attitude to welcome the sounds-negative comments from others. I was a Java lover during the time Java was not so popular as nowadays, now I am a Perl and Python guy, but still with respect of Java.
It is right approach to realize the shortcomings of what you are favor in, by comparing with other things. Java is not god, so do not worship it. It has pros and cons. Java community is not a cult group, unless your mindset is reformed to accept Java alone and you are actually caught.
Being technically spiritually mature is through knowing and facing the imperfection of your preferred technologies. Such topics, though stirring up our calmed mind, are greatly helpful for our souls.
Juguang
Not Java Rant !?
"For those folks who will think this is anti-Java rant ... "
Well, unfortunately it is. I really don't understand why O’Reilly keeps publishing this kind of content on OnJava. Please just make a "Java Rant", "Java is Over/Dead", "Beyond Java" section or whatever and go full speed with this on there.
Or link the entire RoR, Ruby and .Net community on the front page of OnJava and get done with it.
Regards,
Horia Muntean
Perl v Java
If you are saying that if you hire people who don't make mistakes then no mistakes will be made, I see no error in your logic, errr. And blaming the victim is always a good cop-out.
But people (this was 7-10 years ago) were lulled into a false sense of security: they heard "you only need one line of code compared to 20000 lines in X" and "it should be simple to do simple things" and didn't realize that this meant they needed *much* more discipline such as statement-level documentation and attention to structuring than if they used language X. A hacker-friendly language encourages you to hack and to become a hacker and to cause the longterm problems that hacker's are prone to, without exceptional discipline.
Perl v Java
Certainly one of the goals of Perl has always been to make it possible, even easy, for novices and non-programmers to be productive without having to learn much.
Let me restate the question though -- if you're betting your business on people without much programming experience and skill writing maintainable, useful code, is the language they use the primary fault? If you hire someone who only knows how to balance a checkbook to keep the books for your business, does it really matter if he uses a spreadsheet, a paper ledger, a personal finance program, or a domain-specific accounting system?
Perl v Java
Because I've seen your code :-)
No, seriously, a language like OmniMark, which was (and is) the language of choice for people doing serious markup processing for high-end publishing (who can afford it) was specifically designed to be as readable as possible, very successfully.
Perl was not designed with a sense of making it natural for the user to write maintainably: Larry Wall is quite explicit about this : see his "Style not enforced except by peer pressure" at http://www.wall.org/~larry/natural.html (a page startling for its bogosity). Nor was it designed so that people writing bad code have any idea that their code will be unreadable: "If a language is designed so that you can ``learn as you go'', then the expectation is that everyone is learning, and that's okay."
Perl v Java
I've actually heard the argument before that Java is like the spork of languages, it's hard to hurt yourself really badly with it. So I would argue that it's easy for you to use a larger group of less experienced coders to do a project with Java.
The question then becomes, does using more lower skilled programmers better than using a few more skilled engineers in a more expressive language.
I'll always concede that it's easier to write obfuscated code in Perl than it is in Java. But I can write in two lines of Perl what it takes two pages of Java to write.
language agnostic
I concur about your success strategy in the most part.
I somewhat disagree with your second point. Sun is pushing a Java technology stack, only a part of which is Java. When people buy into Java they are buying into a whole set of related technologies. I haven't in my experience heard of folks starting Java projects without using any of the built-in libraries, and to some extent add-on libraries like XML parsers, database access, GUI toolkits, web server technologies, etc.
Another point that I forgot to mention in this article was Sun's critical failure to endorse a single technology for database access. That left developers on different project using different core technologies for something as rudimentary as database access. This is something that Microsoft gets right. Microsoft has had several standards, but they generally only endorse one at a time. So engineers always know what the current technology is and can train to that technology and use it on multiple projects.
language agnostic
I believe that the success of a software project is only marginally determined by the selected programming language. If you have a bunch of people that like language X, let them use language X, whether it is Perl, PHP, Python or Java. That's the best guarantee for success.
Another remark: it's not because some framework is not ok that the underlying language is not ok.
Perl v Java
Why would you expect that people who can't write maintainable code would succeed with any language?
Perl v Java
"One would have thought that the success of Perl before Java would be self-evident."
You're trolling, right? I have seen a long, large running publishing company dragged to its knees because it had adopted write-only Perl. If they had adopted Java (or probably anything else!), they would have avoided much pain.
you can't blame java...
for people making bad technology choices. the people who broke ground with EJB 1.0 *knew* they were going with a "point O" technology.
by adopting the cutting edge, you inherently add risk to a software project. you get your just deserts if you choose a green technology based on marketing hype alone.
further, there were plenty of Perl and other (non-Java) web applications that failed during the dot bomb period... singling out Java
how can you you claim not to be "anti-Java" when you use inflamatory language like "Java nightmare"?
while you may be correct that Java won't live forever... it's definitely not going away anytime soon with billions invested in mission critical and highly available infrastructure.
or... maybe all we need are some php programming hacks to fix the world.
Time for you to step down off the technical ladder!
Cobol is arguably a better language? Change is not always good? Companies lie?
You really think all of these fortune 500 tech companies that use Java technologies were all lied to by Sun? That Sun conned companies like Oracle & SAP that Java was the only way to go? Experienced technical companies?
I hope you don't get paid to get post on here. Your opinion is total crap. You belong at a company in a basement office coding away at Cobol forever with all the other crusted die-hard mainframers. I suppose next you'll tell me that RSS, AJAX, or Web Services really isn't needed as well.
What about the good Java has done :-)
As I put at the bottom, I think there is a lot of good in Java. In particular, you are right, positioning garbage collection in the mainstream. That's good stuff.
However, one has to always question the cost. Sun's scorched earth policy of destroying every other web server technology by beating the 'Java is the one true language' meme into everyones subconcious had a real world impact. It hurt programmers who lost their jobs and had to struggle against Sun's PR. And it hurt companies that invested in technologies that weren't ready for prime-time.
Frankly, I think if Sun had been a little less agressive then we wouldn't be seeing a lot of this backlash now.
stats
The tough part there is deciding on what constitutes failure. In my experience, Java projects tend to fall over before they ship anything. Primarily because a lot of time is spent on a super detailed architecture and process. Where ASP.NET projects (along with Perl, Python, PHP, etc.) tend to fall over when the code far outstrips the complete lack of any architecture investment. And you end up with something that ships, but is completely unmaintanable spaghetti.
I think that clearly 'not shipping' is failure. But it could be argued that shipping spaghetti is also failure. In my experience the companies felt that the spaghetti code was a 'problem' but that the projects, having shipped some code that generally addressed their problems, was better than nothing.
What about the good Java has done :-)
I for one am enormously grateful that popularity of Java has finally nailed the myths that anything with a VM or garbage collection is a toy / useless / too slow for real world tasks.
For that, if nothing else, Java has been a huge step forward :-)
Java is done?
What I believe happened is that the wrong technologies were created. The complexity and the inflexibility of the J2EE technologies have completely overwhelmed people. You have to use tools and you have to depend on an appserver and have it supported to be successful. Or, you have to hire Ace developers that will be expensive to use for any length of time that you are not selling product.
Now, the WS crowd is adding more complication and trying to neutralize all language platforms so that noone can benefit from the speed and performance of natively supported RPC. The Jini platform provides a vast improvement in security, throughput and choice...
We'll see who wins...
stats
What would be interesting is to know if more Java projects failed, as a percentage, than projects in PHP, Perl, etc. Since so many software projects fail, it's hard to know if Java truly contributed to that, or if they would have failed anyway if they had decided to switch to Ruby or Lisp instead of Java at the time.
Re:
What you write has a lot of overlap with the topic of lesscode.org – a group weblog by Ryan Tomayko and a rag tag group of developers. You may want to have a look. For a good example of the spirit of the site see this article:
http://lesscode.org/2005/07/21/motherhood-and-apple-pie/
(Unfortunately, the quality of articles lately is… not quite uniform, so please ignore the last six weeks or so and look at the archive instead. The issue is known and is being addressed.)
"Scalable" Isn't
If I never hear the phrase "It isn't scalable" about any technology (as if it were meaningful with that little context), it will be too soon.