Ask HN: Why do big companies tend to only build with Java?
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 ] threadI 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.
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.
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.
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.
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.
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.
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.
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.
"Taking months/years to get something off the ground" has little to do with Java itself and mostly to do with corporate project lifecycles.
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 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.
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.
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.
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.
... 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.
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.
* There are a number of alternative languages to choose from that can interoperate on the JVM (Scala, Clojure, JRuby, ...)
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”
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)
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..)
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.
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.
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?
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++)
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!
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!
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.
I'm a bit confused, you have experience with Java, or you don't?