Tuesday, June 29, 2010

The Problem with Java and C# ...

I'm going to stick with saying "Java" in this article, but the same argument applies to C# as well. Replace accordingly.

There seems to be a lot of bad sentiment aimed at Java these days. Either complaining about the verbosity of the language, the bloat of the surrounding tools or the mentality of the developers that use it. Other articles seems to talk about how rapidly that community is shrinking or the futility of the innovation in the community.

The problem with Java is not the language, it's the hiring mentality that goes behind it.

When companies decide to play in the "enterprise" space, they feel they need to use programming languages that best fit with those environments. This usually means Java. This is nonsense. Facebook, Twitter, Google and other hot new companies have incredibly scalable architectures, many without SQL, LDAP and Application Servers. We know there are other/better ways to solve the scalability problem. Also, you have compatibility with legacy systems without requiring an Oracle Application Server. If you need to have an army of Operations people to tune your app server, you might want to reconsider your architecture.

Another factor in this rationalization is the ability to hire from a wider gene-pool of developers. There are certainly more Java developers out there than nearly any other programming language. When hiring a Java developer many of these companies hire tactical skills, not general skills. Do you know Struts, JSF, Hibernate, Websphere, etc.? And I can understand why. If you build a product that is going to have a long life-cycle, you have to assume the software is going to have to live beyond the developers that assembled it. If the application is written on niche or trendy languages or tools it will be harder to replace these developers later.

This is broken thinking.

People will do what you reward. If you reward blindly learning software packages without understanding what their benefits and limitations are you will end up with a development team full of automatons. If you reward understanding computer science fundamentals, the best tool for the job, code simplicity and readability you will end up with a better software product and it will take less developers to build / maintain it.

And don't read this the wrong way. I'm not implying that all Java developers are sheep. There are many, many awe-inspiring Java developers out there. Sadly, there are far more sheep.

Can you blame the developer? No. The common sentiment is "If I stick with Java, I'll have a job." ... and it's mostly true. This is usually followed by "Do I like my job? Meh."

Yes, it is harder to hire these sorts of developers. Your interview process will be lengthy. You will eliminate more candidates. But do you want to work in a brain shop or a body shop? Which is harder: reading clean understandable code in a new language or reading verbose bloat code in an understood language? Which is easier: reading a new DSL or pages of XML?

What is the impact of developer farms that are hired for tactical skill sets instead of core understanding and passion? An uninspired workspace. A breeding ground for "[Flavor-of-the-Day] Coaches" who feed off the malaise of the corporation. "Certified [SilverBullet] Masters". Higher turnover. More developers pounding in Feature X, Y & Z without a care for the big picture. 

Let's not throw out the baby with the bathwater. Don't diss the language. Diss the companies that foster this lousy work environment on us developers. Developers, work on your core skills. Don't let yourself fall into the "must master the Java stack" trap. Learn other languages and see how they tackle the problems. Look under the hood at how the libraries you use today work and what the alternatives are. Learn new API's, but then learn their implementations. Review your algorithm books and decide if there are better ways to solve the problem.

Don't go wide, go deep and don't work for body shops.

6 comments:

Mitchell McKenna said...

You make some good points. When I worked at IBM I noticed a significant number of the programming jobs were generic enterprise Java jobs.

I started off in a Java background, and since learning other languages, I often come across problems I can solve in a fraction of the time with another language. At my current job I'll see a PHP product developed in half the time than an equivalent product in Java.

I like the "Don't go wide, go deep" mentality; yes try many languages, (try many frameworks!), but don't be a mediocre programmer in all of them, find the ones best for the job, then master it.

Klaus Villaca said...

What you wrote goes for those one that aiming Software Architecture, in this case Java is one more tool in your toolbox. I'm working with IT since 1990 and have worked with many languages (C, C++, Cobol, Foxpro, Clipper, Dataflex and Progress proprietary languages, Pascal, Fortran, VB and Java in several OS's like Xenix, Unix, IBM OS's, Linux and Windows's), my choose for Java is because with that we have back compatibility, when apart from C ANSI, it does not happen with others languages, and that means for the company will have your system being upgrade for long time, I don't see Java verbose as bad, no, it's very desirable, because with it you have more control of what is happening in your code, try .NET and let me know, there are many super class that does everything without you really know how, and if you work in IT for some time, you learn or learned in UNI that if you have 0,0001% chance of something happen, that thing will happen, that the time expended to create the system usually is 10% of his lifetime, that for better that is your code is, always problems will arise, and in the end you will be re-writing the wheel to solve this lack of information that you have. I agree with you that most of programmers/developers today choose Java because there are more jobs, though it's not just happen with Java is with IT generally speaking, today we have many Project Managers that don't have at least one piece of knowledge about technologies that they are working with, there are BA's that are nothing less then type writers, and developers that put into CV something like 11 years experience and even know how to deploy one application. IT area is growing up too fast, faster than good talents arise and it's really bad, because create this sort of misunderstood s, quite few people have one 3D vision about what is the best for that project, most of then are followers of this phrase "If I just have one hammer as a tool all my problems will looks like a nail's"
As you told PHP is not a bad language, though doesn't have a good structure and is harder to maintain than Java, they choose Java, because they save the investment made, just because this, and is just because that COBOL is still wide used for financial institutions and still will be for long time. If you want have one good example, thing that you need invest one small amount of your money like $100k that's quite small for enterprise projects, do you will invest your money in something, that when need some improvement/enhance maybe 2,4,6 or even 10 years late you still will find out people to do it, or with some language that when they release 3 versions, hardly will be 80% compatible with the old code and such probably you will not find out people that will enhance your code, leaving as the only option re-write all code from ground, and expend more money?
Companies doesn't care about if that framework, or language is verbose, new, fast or whatever, they care about money, and Java has the better package, not the silver bullet, just the best package to solve most of problems and guaranteed legacy as people to do it and strong community. It's just not the language.

Edi Moraru said...

Hi.

I feel the same.

But I think we need to make a distinction : there are developers/programmers that want to advance their skill, some that only want to get paid (you know, the 9-to-5 crowd), and some that will do anything not to do the work.

So, we need to acknowledge that only some developers are going to learn new languages, new frameworks, to try to improve their skills, to refactor code.
This is the target for Software Craftsmanship and for Agile.

And from what I've seen until now, the percent of those willing an improvement is small. Bigger the company, smaller percent of those willing is also an observation of mine.

Also the profile of the company is important : does produce and sells some products or has clients from government, because the bureaucracy is like entropy, it's spreading always and corrupts all. A company needs clients who push for quality, and government is anti quality oriented.

Thank you for a very interesting blog post.

KevDog said...

Can a brother get an "Amen"!

KevDog said...
This comment has been removed by a blog administrator.
Adam Burry said...

It sounds like you are saying employers hire based on the length of a laundry list of tech, which encourages developers to "learn" as much tech as they can, but never to any depth because they have to move on to the next buzzword for their résumé.

I don't think that is the case. It may be the case that some developers operate that way, not because all employers hire based on buzzword count, but because every employer is looking for something different.

I think it may be especially true that inexperienced developers look to add buzzwords to their résumé because they need some way to stand out to get their foot in the door for the interview.

I agree though that some employers focus too much on their particular domain and not enough on fundamentals. Someone with strong fundamentals has a good chance at being good at whatever they try their hand at. I guess employers get distracted by the short-term pain of the ramp up time, without thinking about the longterm value of having strong employees.