Ask HN: Why do big companies tend to only build with Java?

51 points by mootymoots ↗ HN
I want to understand one thing at major companies: Why Java?

Is this a company investment thing, they're in bed with IBM? Is it a mentallity thing? Is it a compiled language thing? Is it a security thing?

It's certainly not a speed thing. Every team I have had experience with working with on a Java platform has taken ages to deliver anything. CMSs that I could build rapidly with the likes of PHP/MySQL take months/years to get off the ground. Change is slow.

Believe me, I have zero experience of working with Java, but I need to understand why they do it. Have you experienced rapid development teams using Java?

56 comments

[ 0.25 ms ] story [ 128 ms ] thread
I'm in South America, but I do work for a big company.

I believe that we use VB6 and .NET because that's one of the two main platforms student learn (the other being Java), and programmers can be treated as interchangeable pieces. You're certain to receive thousands of applications for a job posting, and get outsourcing cheaply and easily.

Are the results good? I believe they mostly aren't, not because of a flaw in the platforms. And yes, change is sloow. There are too many stakeholders for anything.

I've heard of agile development with Java or java-likes, and .NET as well, it's not a platform thing.

Thats an interesting point about employees. I've seen a Java team take 6 months to hire 3 new developers in London. That's before development even started :)
I think it stems from the fact that you can almost always find a Java library for whatever enterprise product you're looking to work with. I have yet to find a major company (not a start up) that did not release some sort of Java API to its product. Just an observation and my experience, not rooted in any "scientific" study
You can do rapid development with Java--it's less a condemnation of the technology and more the process that happens in big companies.

I've worked on contract in large and small companies, and the amount of paperwork to go through in large companies is ASTOUNDING. For example, we once had to get a test account created in the test domain (not even production). It took 23 emails, 4 IT requests, and 6 hours to complete--and that was the "accelerated" path.

But bureaucracy is only part of it. The real reason it takes a company to build something so freaking long is testing. Not just test-driven development (that's crazy talk, by the way), we're talking testers. Lots of them. Now, I'm all for testing (yay testing), but companies go to the extreme. I've had more than one of my projects take three to four times as long to test as they took to develop. Sometimes you luck out and get really good testers, though, so then life is peachy.

But to answer your question about why companies use Java, it's because it's widely taught, and programmers are thought of as interchangeable pieces. They can bring over a ton of people from out of the country for cheap labor, or just hire a bunch of D+ CS students and put them in cubes and give them detailed specs and just let them go at it. There's no thought to it--they're cogs in a machine.

Also, sometimes technology choices are just at the whim of people higher up--they have a favorite technology and push that as "the way," even in situations where it doesn't quite fit. Such is life.

To sum up, companies are slow to develop because of overhead and bureaucracy, and they use things like Java because they want cheap programmers, not good ones.

Edit: I should clarify something that came off as really presumptuous and pompous. Java isn't a bad technology, per se, and there are plenty of great programmers who use it. My point was that Java developers are easy to find cheap, so that puts a vote in the win column for larger enterprises.

That being said, there are a lot of really good reasons to use Java, and if you know Java really well, you can put together a CMS as fast (if not faster) than somebody slinging PHP or Python or whatever their language of choice is.

My main goal was to address why enterprise development is often considered slow by startup standards, and what causes that. I know a few really great Java programmers in big enterprises, and I know they often get frustrated by the glacial pace of enterprise development.

The last time I played with Java server technologies, I found the edit debug redeploy cycle to be ridiculously long. What is the start of the art nowadays?
It's mostly an ecosystem thing. Large companies follow the lead of their vendors and Oracle/IBM/HP all push Java. There is a vast array of third party tools and software packages for doing boring enterprisey stuff like monitoring and integration. If you want to integrate or extend one of the big ERP or CRM systems that is mostly Java. At this point there are lots of people that can be hired with passable Java skills and most consulting outfits have large Java programs. Admittedly this is something of a positive feedback loop that got started because the big vendors stared it 15 years ago.

As for team delivery speed it is certainly possible to deliver quickly. The dynamic languages have definite advantages over Java. There is less XML/property/configuration stuff to manage for instance. But the Java frameworks are actively developed and they get better all of the time too. Delivery speed is mostly a team and organization thing. Large orgs can take forever to deliver the simplest of things. It can take forever for people to decide what they want. You might have to get permission from three different VPs. You may have to schedule a series of meetings to have a decision made and it can take a couple of weeks the find time when all stakeholders have open time on their calendars. You may be dependent upon cooperation and resources from another team that isn't really motivated to help you because they have their own stuff going on. So it's not really a technology problem, it's a management problem.

There are a plethora of reasons that the enterprise uses Java and many of them are really good reasons but the main reason now is inertia, so many enterprises and vendors are invested in Java that to divest of Java just does not have a good value proposition, given the fact that their has not been a major revolution in languages or run-times, no one has had the stomach to try to move off in a serious attempt.

To understand it we have to look at the history of when Java came about and what Java brought to the table. Most people think it was a more modern language that was what won but the reality is that was just icing. The real winner for Java taking over was the VM, at the time Unix was dominating the server space (in particular Solaris) but Microsoft has a through monopoly on the desktop. So here you had all of development on one OS and all of the runtimes on another, The promise of Java was that your developers could continue to develop on desktops while delivering to Server architecture, it was not always totally smooth but it did work and their in lies the revolution that Java brought. A common development platform across architectures. It seems so common today but at the time it was huge, it had the potential to save companies millions if not billions.

Fast forward to today and a big issue with the enterprise is labor, and lets face it trying to take the road less traveled can introduce unnecessary risk into the enterprise. If a company is not in the Vally the quest to find a Ruby or Python or Node.js developer can result in not finding a single candidate, this is far more risky than another month of development time to stay with Java. They are totally different concerns, a small scrappy start up, can afford to kick the bushes of local groups to find a guy playing around with Node.js, an enterprise has no systematic way of figuring out if the kid at the local users group is an expert at Node.js or has just been playing with it for 2 weeks. To me this is the biggest one, talent is available locally and even if it is not, the big vendors and even the recruiters can dig someone up fast. This alone mitigates a lot of risk from the organization.

Second most enterprise software is built with Java and has Java API's, SAP, Oracle, IBM and many of the other offerings these guys use are in Java. I like to poke a lot of fun at some of those systems but the reality is implemented correctly they can save a lot of money and time and unlike in a start-up where every penny counts in the enterprise vendor supported systems are considered a good thing. They allow the company to focus on their core business while leaving system development to a vendor.

Which brings me to my last point, there is a new revolution underway, and I do believe that in the near future the cost benefit analysis is going to be so great that the enterprise will not be able to ignore it, and that revolution is SaaS. For the same reason I just highlighted, (focusing on core competency), SaaS will be huge, now not only will the enterprise not have to concern itself with maintenance of custom systems, but they will be able to offload support as well as infrastructure. Getting out of the infrastructure game for the enterprise will be huge and may herald the end or Java's dominance.

You make Java's decline sound almost inevitable. Perhaps it is. But Java retains significant performance advantages thanks to the (by now) well optimized JVM, and SaaS has actually helped it replace more elegant languages like Ruby in contexts where performance is critical, since the whole code base doesn't have to be thrown out, and Java can be dropped in strategically.

A good talk on this is "Twitter: From Ruby on Rails to the JVM" by Twitter's app services chief Raffi Krikorian http://ontwik.com/rails/oreilly-oscon-java-2011-raffi-krikor...

The fact that Twitter just hired Oracle's Adam Messinger as its new CTO seems to be a strong sign this direction is continuing. http://techcrunch.com/2011/11/07/twitter-nabs-former-oracle-...

Certainly languages like Ruby and Python will continue to post performance gains as their interpreters mature. Certainly the migration of e.g. Lisp (Clojure) and Ruby (JRuby) to the JVM will accelerate these gains. SaaS will allow a mixture of languages. And surely other language platforms will be Good Enough for many startups and for smaller apps at large companies.

But at the edge of the performance envelope, among memory managed languages, Java still seems to be a big winner, at least if the folks at Twitter are to be believed.

I apologize if my writing inferred that Java's decline was inevitable, it was not my intention, rather my intention was to point out that Java's dominance is related to some factors that are now changing and may give room to other options. It may or it may not, I generally try to stay away from predictions because there are many variables that can affect the outcome of the future. As such I was not trying to predict the rise of alternative or the fall of Java just merely stating the point that SaaS will allow vendors behind the service curtain a lot more flexibility it what they choose to provide those services.
Fair enough, I enjoyed your comment overall, a lot of good points. Maybe I read too much into it. Apologies if I did!
No it did read like I was predicting it's demise, it was not my intent but it did read like it. Thanks for the kind words, I enjoy participating here and it is always nice to have someone say they enjoy my contributions.
> Getting out of the infrastructure game for the enterprise will be huge and may herald the end or Java's dominance.

No it won't, JVM usage will just shift to wherever the need for massively scalable systems goes. If that domain shifts from in-house enterprise development to SaaS companies like Salesforce, the JVM will still be a top contender for those kinds of projects, wherever they're housed.

Statically typed languages are favoured when you're working on a team with 40 other developers and you want the idiotic changes being made 5 desks over to break before they check in, not after you've pulled their changes.

Autocomplete also makes life staggeringly easier, as do strong refactoring tools.

Not having to deal with memory management is also a big plus.

When you put those requirements together you end up with C#/Java. Which is why a fair number of places whack together UIs in C# and server side code in Java.

On the other hand, maybe you wouldn't need 40 developers on the project if you weren't building it in Java...
Once your code base gets to a certain size, the feature set gets big enough, and the maintenance starts stacking up, you need a more robust language.

Sure, plenty of web apps can run fine on Ruby, but even then, many of them start looking towards a language thats easier to maintain.

Good developers can move fast in Java, bad developers will move slow and screw up, even in Ruby.
Obviously, every Java project with hundreds of thousands lines of code can be written by 2 developers in Ruby in a weekend ;)
It's a safe choice. It is easy to find Java developers with enterprise experience. There are lots of vendors and consultants with Java expertise. There is a lot of corporate mind share around Java. And at this point, most companies have a large investment in Java (or .net) so it makes sense to continue on that path.

"Taking months/years to get something off the ground" has little to do with Java itself and mostly to do with corporate project lifecycles.

Good threading support (no global interpreter lock or anything like that).

Very fast.

Unicode strings.

Some measure of type checking (probably appeals more to large, enterprisey projects). This also makes IDE autocomplete easier.

Lots of libraries.

Cross platform.

And yes, a large pool of developers.

Not too many languages can check off all those boxes, making Java a sweet spot for a lot of enterprise development. Probably not a good fit if you just want to throw together a CMS, though.

I believe that the structure of the language helps translating OO design to code. As OO is the preferred way of enterprises to describe their products (which may not always be the best way), they tend to think Java will make the product better.

I think Java right now is easily understandable by blue collars (not the code, but the architecture and the design part). It may not be the right choice, but big companies try to avoid the unknown and they tend to think that things they can understand (OO being an example) are better than the other options.

it's not just big companies that use java. We're a small company (15 ppl) and have built our backend in java and the frontend in PHP.

I'm not a developer but I think at least part of the reason for building in java is the abundance of libraries (i.e. Apache Commons). We also just do POJOs/Servlets so development can be rapid. I think most people think of J2EE when they think of big companies and java.

Most of these answers don't seem to be written by anyone actually involved in "enterprise" development.

Here are our simple reasons:

* The JVM is fast.

* The JVM can take proper advantage of multiple cores directly (no GIL).

* The JVM is efficient compared to other runtimes.

* Java is type-safe.

* There's a library for everything, and libraries are generally well-documented, unit-tested, and provide stable releases with binary/source-stable APIs.

* There are a number of alternative languages to choose from that can interoperate on the JVM (Scala, Clojure, JRuby, ...)

I've worked with plenty of JVM/Java-based projects that shipped quickly. There genuinely isn't anything else I would use server-side.

Nah. Those are the reasons that an organization would like to list for using Java. But "kls" nailed it above. It's mainly inertia and labor availability at this point.

The reality is that most enterprise projects are generally so many layers of lasagna code that JVM performance is about 20 down on the list of things to blame for poor performance.

If anything, they are reasons that enterprises aren't in any kind of hurry to abandon Java.
Right which was my point above in setting the history of how we got here and why no one is really interested in leaving. The history is very important to how Java became dominate and created the top reasons, which I would content are inertia and labor pool. The reasons bullet pointed above are why no one is in a hurry to move on, it does what it is supposed to do and the enterprise is happy with it. Until the cost/benefit is blown away, they will continue to be happy with it.
Nah. Those are the reasons that an organization would like to list for using Java. But "kls" nailed it above. It's mainly inertia and labor availability at this point.

... except those are the reasons our organization uses Java.

Unfortunately, it seems like this doesn't fit the narrative that some people want to have about the JVM and Java.

It's mainly inertia and labor availability at this point.

Perhaps, but you can't ignore the reasons that the inertia and labor pool came to be in the first place, many of which nupark2 lists and which are still valid.

I'm excitedly curious about when this bullet point has come up as a selling point for the JVM in "enterprise" development:

* There are a number of alternative languages to choose from that can interoperate on the JVM (Scala, Clojure, JRuby, ...)

This is spot on. One point to add though: Java is remarkably maintainable due to the high commitment to backward compatibility, great tools, availability of standard skills and the relatively simple syntax ("conciseness considered harmful"). This shouldn't be underestimated in an enterprise setting....
There are good answers throughout this thread but the thing I find a lot of people forget is support.

Startup founders and small businesses tend to have more talent available to them. When you have 4 guys with MIT degrees you can hack through problems so you don’t need support. But if you’re a big company you sometimes have to settle for the day laborer. The guy who can do the grunt work coding but who slams on the brakes when he runs into any kind of problem.

As someone running a shop with those type of workers you have a choice. Have them wait for one of the more senior people to help them or throw $300 at the problem and have them call support.

This doesn’t produce the most elegant code but most big companies aren’t interested in that anyway. If it works and crashes relatively rarely most corporations are fine with it.

Unrelated to that it should also be mentioned that companies like IBM and Microsoft market to non-IT execs where as open solutions don’t have marketing departments. There’s a reason they say “No one ever got fired buying Microsoft”

1) Corporations don't understand IT. To them it's a cost center, not an enabler. So to minimize costs they must find developers that are (a) easily replaceable (b) cheap to hire

2) Sun did a great job marketing Java in the late 90s and early 2000s. So corporate managers felt safe adopting Java; it was the "in" thing. And as kls said, corporations have a lot of inertia. Why break something when it's working? (It's due to this mentality that some corporations still run VB6 and COBOL apps)

    Corporations don't understand IT
I wouldn't be so dismissive. The people are pretty smart and switched on. Their choices are driven by different priorities though.
Its a well structured, well thought out language that somewhat feels like an extension of a lower level language, like C. Generally, companies working on big projects want developers who are comfortable with a wide variety of programming concepts, including using interfaces, modular code, etc and Java, and its ecosystem, helps to reinforce these types of practices. Static typing is also critical for a larger application, something like PHP is really just a scripting language for front-end display and if thats all you have used you are probably missing out on a lot of larger CS concepts
The success of rapid development is more a function of the team, than of the language used. It is wrong to blame Java for the failures of poor developer teams.

Java is stable, has plenty of libraries, lots of tools, is friendly to refactoring, testing, and it is not such a bad language. Just take a look at the tools developed in java by good teams (eclipse, apache, joss, spring and so on..)

I have been doing Java for a long time, and while I personally prefer more modern languages I have found that if I have to load up and work on someone else's code, my life is much easier if it's in Java because the tooling (specifically refactoring support) is so good. So even if I inherit an old, awful, "big" codebase, I have a good chance of wrestling it into shape by pushing it around in Eclipse or IDEA, with some reasonable guarantees that I haven't broken anything along the way. So the fact that I'm not entirely doomed in this case (as I recently felt when I inherited 300k lines of very bad Python) is a good selling point.

So as a common-denominator for large codebases with average-quality developers it makes sense in the long term, although it's not terribly fun.

Knowns. I think it's mostly because of the 'knowns'.

Removes some uncertainty around planning maintenance & operational costs. Java developers are plentiful and framework training/certification programs are out there for the 'feel goods'.

Also... turns out, .NET is adopted for the above reasons as well.

As a former .NET guy, I was just going to comment on the fact that the Enterprise adoption of Java nearly exactly mirrors the Enterprise adoption of .NET. All of the complains and justifications sound exactly the same.
Besides the advantages listed by others, Java make it easy for a team of developers to code together, not just at the same time, also across timeline. After you leave, the next guy coming in to maintain your code has a much easier time to understand the code. Big companies value that a lot.
Because Java is strongly structured, it's easier to bulk hire and fire programmers into and out of large projects. The ramp-up time is shorter.

And that forced language structure can function as a rudimentary safety net for mediocre programmers.

From a large company's point of view, it is a cheap and homogenized programming force. You, I and Joel Spolsky might care about the "good" programmer that massively outperforms other programmers. Most businesses want cheap and reliability.

Add to that a market of off-shores and other workers that fit the "cheap" bill and you end up with dominance. When's the last time you saw a H1B that programmed in Haskell?

Cheap? Really? In corp world java dev with 80-100$ an hour is normal (in AU), not cheap, really.
I also do believe it is the ecosystem. You wont find the amount and variety of tools for any other programming language. Just look for Enterprise Search Solutions (semantic, linguistic, etc.): the majority is written in Java.

How did the ecosystem grew so big? Java is free and is easier to learn and faster to develop, compared to other "big players" (e.g. C++)

The code we're writing today has an expected service life of ~15 years. Java code written according to current best practices will still run well, with minor maintenance, 15 years from now. Oracle and the JCP won't allow any changes that seriously break backward compatibility.
Here we work with scrum and have a pretty agile development cycle. I really believe that if we were to develop our site ground-up, we would use JEE again for the same reasons some of you've pointed out... and actually, we're doing it!

But, for example, many of our webpages are made with PHP using some CMS (Typo3) because it's perfect for this. Our mobile site uses our Java webservices from PHP too.

I've been working with JEE (formerly J2EE) and JSE for some ten years and I know of Java's (platform and language) problems, but I think that they are surpassed by its capabilities, tools, resources availability, etc.

Do I want Java to go away? Why I ask? It works! It's not perfect, is not shiny, is not "agile", but it gives management that warm feeling of cash flowing in. Oh! And it gives me a job!

Here we work with scrum and have a pretty agile development cycle. I really believe that if we were to develop our site ground-up, we would use JEE again for the same reasons some of you've pointed out... and actually, we're doing it!

But, for example, many of our webpages are made with PHP using some CMS (Typo3) because it's perfect for this. Our mobile site uses our Java webservices from PHP too.

I've been working with JEE (formerly J2EE) and JSE for some ten years and I know of Java's (platform and language) problems, but I think that they are surpassed by its capabilities, tools, resources availability, etc.

Do I want Java to go away? Why I ask? It works! It's not perfect, is not shiny, is not "agile", but it gives management that warm feeling of cash flowing in. Oh! And it gives me a job!

I'm a Grails advocate, and can be pretty productive in it. This is coming from someone with 15 years of PHP experience (sprinkled with some other tech), and I'm pretty productive in that as well. There are some aspects of projects I'm actually more productive in Grails in, which is a byproduct of the groovy/java language syntax than anything else. GORM is a dream to work with for 90% of the projects I do, as opposed to any PHP-based ORM, for example, and even Rails' ActiveRecord. Obviously just "imo"

Probably a bit off topic, but PHP/Ruby/Python/Perl scale up much easier than Java scales down. And there's fewer large scale problems/apps than there are smaller scale stuff, so we see far more usage of PHP/etc in most day to day work.

Java scales. You can be slow or fast in any language.

I'm a bit confused, you have experience with Java, or you don't?