Second, JRuby 1.1b1 has been released and as expected is considerably faster (see item #5 in this link) than the standard “MRI” runtime. JRuby joins Jython and Rhino in providing a JVM-based runtime for a dynamic language, with features designed to help developers mix and match the dynamic language code with Java code.

See the trend here? Python, Ruby, and JavaScript are emerging as the dynamic languages of the future for .NET and Java developers.

The hard work done by Sun and Microsoft to make their VMs work well is being leveraged by the next wave of languages. Threads, high performance I/O, memory management, and portability are all features that are quite expensive to get right, and the .NET and Java platforms have pretty much achieved that at this point. (Piggybacking newer, higher-level languages on these mature runtimes means that you get a mature new language runtime faster than if each language’s runtime were built from scratch and painstakingly debugged in isolation from the others.)

There are still some hurdles (performance, type safety fears, lack of mass market acceptance, ECMAScript 4 standardization and adoption, etc.), but in 2 or 3 years, things are going to change dramatically in the web application development world. The seeds of this change are already sown, and it’s just a matter of time. Threads, SQL, OOP, and garbage collection are all features of web application architectures that were initially controversial, but have now met with general acceptance. Dynamic languages are clearly the next step.

Obviously, Java and C# are far from dead, and in 10 years people will still be coding in Java and C#, because as with other languages like C and assembly, the newest and highest-level language isn’t automatically right for every project. But if you’re building web applications, most of what your code does falls into the categories of string manipulation, collection operations, or file and socket I/O. Image processing, crypto, full text search, and other CPU-heavy, byte-twiddling features may be part of your application, but you’re not writing the image scaler, RC4 cipher, or inverted index yourself; those are done in a library, probably written in C, and you’re just calling it. So your needs are likely to be similar to the sweet spot of dynamic languages: maximum expressivity and the fancy features to let you write clever code, making you productive and making the code as clean and elegant as possible. In other words, they put developer productivity first (lower labor cost and shorter development schedules) at the expense of runtime performance. Since hardware gets cheaper over time but code gets uglier over time, this is probably the right choice to make for most web application projects.

Another interesting benefit of layering instead of starting over is that the integration between dynamic languages and Java or CLR languages is much nicer than managed vs. unmanaged code in .NET or, even worse, JNI in Java. That is, it won’t be a bloody mess to mix and match code, from a technical feasibility standpoint. This matters, because The Big Rewrite is among the Things You Should Never Do. But little bitty rewrites are fine, especially if you have a thorough test suite to help you avoid breaking things. (By the way, dynamic languages are great for writing automated tests.)

Which of these three (JavaScript, Python, or Ruby) is going to be dominant 5 years from now? I don’t think any of them will be. The dynamic language community is fragmented, and the various vendors and big sponsors of these three languages are fairly entrenched already. Microsoft is investing in all three; Google has standardized on Python and JavaScript to the exclusion of Ruby; Sun has hired the JRuby team; Mozilla is heavily invested in JavaScript; Adobe supports JavaScript in AIR but not Ruby or Python, etc.

In fact, if you encapsulated the glue code sufficiently well, you could mix and match JavaScript, Python, and Ruby in your application, and port your hideous hydra between the JVM and .NET. You would be wasting a lot of effort since the three languages are largely similar, but you could do it. Alternatively, you could create a portability layer between the DLR and the JVM a la WxWindows, and write-once-debug-everywhere in a more productive language than Java.

These are all repugnant ideas, but only because as I write this and as you read this, we probably realize that to attempt this today would be a huge task. But what about in 2010? Probably not so gross. What about an application that could be executed on Silverlight, AIR, Firefox, SWT, and Mono, unmodified? How about a mobile app that runs on smartphones regardless of the runtime (.NET vs. J2SE)? Not gross at all, and not unthinkable if your app is written in JavaScript using some kind of portability layer that doesn’t exist yet.

In the longer term, JavaScript (a.k.a. ECMAScript 4) is likely to become extremely popular. As far as I know it’s not quite a perfect fit for Steve Yegge’s The Next Big Language, but it’s the closest thing there is, and it has two critical advantages over Ruby and Python that will make it successful: C-family syntax (which makes development tools cheaper to build) and effectively unanimous buy-in from vendors and developers.

So, what about the other dynamic languages that people are using in large numbers today? What’s going to happen to ActionScript, CFScript, PHP, and VB?

ActionScript and CFScript are pretty close to JavaScript by design; I’ve read that ActionScript 3 is actually compliant with the ECMAScript 4 draft specfication. It’s pretty clear that Adobe is betting on JavaScript. In the near future (2 or 3 years) I predict that Adobe will rev its products and support ECMAScript 4 across the board.

PHP and VB.NET/VBScript will hang around for a long time because they’re approachable and already very popular, but they’ve already peaked, and will steadily decline as developers switch to C# (on the .NET side) and Rails (on the Linux side), and then JavaScript as soon as a serious web app framework and an ISP-friendly runtime exist. Microsoft will keep investing in VB to keep customers happy; Yahoo will keep investing in PHP because it is so heavily invested in PHP already; new developers will find PHP to be an easy starting point for light duty web development, with tons of documentation and free applications that they can download and hack. But PHP will not inherit the kingdom from C# or Java, and the languages which do achieve mainstream success after C# and Java will do everything that PHP does language-wise, and the market momentum around those languages will make them better than PHP at what PHP does. Developers will ask themselves why they would write the client side and server side in two different languages, especially when the server-side language is more expressive and has better portability and libraries. That’s not true yet, but it will be in a couple of years. In 5 years or so PHP and VBScript will go the way of Perl CGIs: still used, but by a community a tenth of the size it is today.

What about the new Java-based dynamic language, Groovy? Groovy is interesting, but it’s too late. The Java mainstream of vendors and developers only recently managed to convince the world of “serious” C++ developers that automatic garbage collection and JIT compiled bytecodes can actually work in a high traffic context. The next battle, to promote the dynamic language features that Java lacks but which Groovy brings, will take years to fight. Once a developer makes a decision to not use standard Java, Groovy is on a more or less level playing field with the JVM-hosted versions of Python, JavaScript, and Ruby, but each of those languages has far greater adoption than Groovy, and each of them has greater opportunity for leverage on other runtimes than Groovy. For a Java developer, once the door is opened to other languages, the only advantage Groovy has is that its syntax is familiar. Compare this to JavaScript which web developers also need to know how to use; why learn a third language (Groovy) in addition to Java and JavaScript? Over time the simplicity of coding and debugging in JavaScript on client and server, together with dynamic-language productivity, will overcome the momentum of the Java standard, and web developers using server-side Java now will gradually replace it with JavaScript on the JVM. Conservative attitudes in the mainstream Java community (including Fortune 500 companies and the many offshore development firms that write code for them) will make this take quite a while – probably 5 years before JavaScript becomes a common part of the architectures that currently use J2EE, and 10 years before Java goes the way of COBOL (maintained forever but not used for new projects).

So in conclusion, keeping an eye on the future value of a technology, including who’s investing in it and who’s talking about investing in it, is critical to making your own investments today. In five years you’re not going to be using the same technology stack that you are today, and your project’s success and your own salary will be tied in large part to how well you invested today.

Check out the 4th message in the thread, with the big code sample.

• Table based HTML layout, and no CSS at all? Check. Heck, the table width % values don’t even add up to 100%.
• SQL in the JSP? Check.
• Making a new JDBC connection for each page view, instead of using a connection pool? Check.
• Unescaped strings in the SQL? Check. (Not strings coming from the browser in this particular JSP page, but you don’t know where those strings originate. Why wouldn’t you escape it just in case?)
• Failing to use a prepared statement? Check. (That would also solve the escaping problem.)
• Using a string literal in a SQL or command line context, so you can’t log it beforehand? Check. Even better, the code makes a query string first, prints it (commented out), and then uses a different string in the actual query. Nice!
• Using the JdbcOdbc driver? Check. (From Sun’s JDBC Basics: The JDBC-ODBC Bridge driver provided with JDBC is recommended only for development and testing, or when no other alternative is available.) I’m guessing that the use of ODBC here is the only reason why the database username and password aren’t embedded in the code sample and posted for all to see.
• Empty exception catch block? Check.

I’d have a hard time coming up with a fake example of bad code that was worse.

But wait, what else has this person asked about?

No way. Yes! Error in Socket and File Writing!
The post includes the router’s username and password, and its configuration including:

• Its IP address, and all of the routes it contains, and all of its interfaces and where they go
• A couple of other passwords stored in the router
• A crypto key that appears to be to a VPN (looks like a pre-shared key, meaning not a public key but one that must be kept secret)!

I’m not gonna say “you get what you pay for” since open source software has served me very well, but I will say that you get what you bargain for. If your bargain includes not looking at the work product of the people you hire, which is to say, hiring the cheapest people available and not supervising them, you’re not going to be happy with what you get.

Of course, this could have been written by a U.S. citizen who works in a cube on-site and makes $200/hour. Point is, hire carefully, and supervise your workers. It seems simple when put that way, but it’s amazing how often companies are willing to hire software subcontractors carelessly (solely on price?) and then pay little or no attention to the resulting work, when the arrangement involves offshore outsourcing.

By the way, the IP addresses in the original post (with the awful code sample) are listed next to the name “Areva”, implying that this code is part of a project for Areva. Who is Areva? They make nuclear power plants. Sweet dreams!

Josh’s Rules (of Database Contracting)

This company would just find new and different ways of embedding Flash, AJAX code, iframes, etc. in MySpace and similar sites, and would then release sample code snippets and example apps that clients would use to build their widgets. Later on they could release some kind of API that made the same widgets work across all of those sites. Clearly they would be the first ones to re-engineer their hacks when MySpace decided to change its code for whatever reason (breaking existing widget embedding mechanisms).

I’m not going to do it, but it’s an interesting idea, and in my opinion, it’s only a matter of time. It’ll probably be someone overseas, in Russia or Eastern Europe who does this, since it’s not terribly well looked upon to sell what amounts to a cross between an exploit kit and an “undocumented APIs” reference for a big web site.

Or maybe it’s already out there, and I just don’t know about it…

Having worked for a few companies that sold themselves as “a magic box that you put millions of dollars into, and great code comes out a few weeks later”, I know that this is a serious misconception. Subcontracting is fraught with peril. Offshore subcontracting is fraught with more peril, but it costs less per hour. In both cases, the peril is avoidable, but avoiding it requires that you manage the relationship carefully.

I’ve worked with offshore teams on a couple of occasions, and in one case I was fortunate enough to get sent overseas to work with the team in their own offices. I think I probably have more direct experience with offshoring than most developers or technical project managers, and I’ve seen how offshored projects can go awry, so I thought I’d share some tips for those of you considering offshoring a software project, or those involved with such a situation already.

One thing to think about first is whether you’ve really looked for folks locally. Pretty much everywhere I’ve worked, the management has been vehemently opposed to posting a public job listing. Simply spending $75 or less on Craigslist was too much to spend for someone who’d probably be paid about $75/hr. Seriously. I’ve basically been limited to finding people I know, from past work or a mailing list or LinkedIn, and if nobody is available, panic! We need more people but there’s noooobody out there! Really? Have you tried?

A second question to ask is whether you could use a part-time (fixed # of hours/wk) or freelance person, and if they have to work in the office or not. If you’re about to hire someone thousands of miles away in a different time zone, you might want to make sure there’s not someone in town who just doesn’t feel like commuting but who’ll answer the phone during your business hours, or if there’s someone with a kid to take care of, who would be happy to work their butt off 5 hours a day in the office, but who needs the rest of their day to spend with the kid. Remember, you’re considering adopting a serious amount of communication overhead in order to get someone to work for you; you might do better to just find a 1/2 time person who is in the next room for a big chunk of each day.

Anyway, let’s assume you’ve exhausted those options and you’re going to definitely hire some folks in a foreign country far away.

Here are some questions to ask about the specific situation you’re evaluating, some of which are similar to things you’d want to ask about non-offshored situations.

Can you fire the developer without firing the project manager? Or are they a team that you have to fire as a unit, and lose all institutional knowledge? This gets even worse as the team gets bigger. Can you afford to can the whole development organization if you don’t like the way things are going? In other words, are you clear on whether you’re hiring a PM and having them hire developers in turn, vs. hiring a company that will act as a subcontractor?

Will the project manager fire the developer and find someone better, if the PM determines that the developer is not working out? Or will they try to cover up for it, or not worry about it since productivity is not their incentive, but keeping billable hours high is? Bear in mind that you may be paying the PM’s company one rate and that the developers may be paid 1/2 of that, and both you and the developers may see that as a really desirable hourly wage. If you think the PM works for you, then the developers should be paid by you, not by the PM, or at least you and the developers should have agreed on what the PM will pay them. Skimming contractor wages is common practice in the US, too, and depending on how extreme it is, it can create serious incentives for the PM to find new and inventive ways to cheat you.

Will the team’s primary language be the primary language used in your source code, and if so, will that limit your options if you decide to fire them and hire someone else? This isn’t a big issue for India, China, and Russia, but for some languages, you might have a very hard time finding another team that can read and understand the source code. You might also find that it’s impossible to integrate a local developer into your team because they only speak your language, not the language of the offshore team.

Are you sure they’re only working on your project, full time, and billing you their actual hours? Again, 150% of a low wage for you may not be a lot of money, but to them it might be livin’ large, and worth the risk of getting caught padding hours. As far as my moderate research can tell, there’s no systematic, reliable, direct way to measure programmer productivity (not that people haven’t been trying for decades to come up with a way to do this), so you pretty much have to have someone on your end working closely with the team who can make a subjective judgement as to whether they really need 12 weeks to do something, or if 8 people are really working on your project all day every day on their end, or if they’re just scamming you.

Do you know that the developer you thought you hired is the same person who is coding for you? This is a textbook US consulting company scam: bring in the rockstars with the stellar resumes for the sales pitch, and then gradually roll them off onto the next new project, backfilling with clueless newbies, at the same billable rate as the rockstars.

Of course, falsified resumes are a problem too, just as they are here. If the company is in another country, they may do things like making up impressive-sounding universities and companies to pad resumes, or just copying someone else’s resume and putting their name on it. I have had a resume sent to me by a colleague who said it sounded strangely familiar. It belonged to a person that we had worked with, and was copied verbatim, with the name changed. I was on a 2 person team with the actual owner of this resume; I’m pretty darn sure the third guy wasn’t sitting in the little office in Mountain View with us unnoticed. In another case, a large offshoring company introduced a team from India and even flew some of them over to meet us. Two of them were supposedly the project technical leads, but in 3 months they never responded to my emails, never checked in code, and never were available for conference calls, and the PM made up excuse after excuse for why they were missing. We received invoices with their hours on them, and I couldn’t get our folks to stop paying for them. I’m convinced that they never worked on our project.

Is the professional culture in the offshore country the same as in yours? For instance, do they work exactly 8 hours a day and then bail, even if they promised they’d get something done today and it’s not done? Will they stay late, work weekends, etc. if you say something is an emergency? Most cultures in the rest of the world consider U.S. and U.K. working hours and work culture to be too long and too intense (and they’re right, but that’s a different issue). A colleague told me a story about an offshore team that was working on fixing a serious production bug which the U.S. team was freaking out about and clearly communicating the level of urgency of, but which didn’t stop the offshore team from quitting at the usual time on Friday and not working again until Monday even though the problem wasn’t resolved. ASAP doesn’t necessarily mean what you think it does, if the person on the other end is not on the same wavelength about work culture as you are. Getting someone to work all night or all weekend may not be negotiable, or it might just cost time and a half, or double, or something like that. Just make sure you have that spelled out explicitly, and if that means you need a “B team” in another time zone, or a local developer resource, so be it.

My favorite model for offshoring basically eliminates the subcontracting agreement, making the PM and developers (and anybody else you want to hire offshore) part of a wholly owned subsidiary company in their country. Instead of treating them as a unit, treat them as individuals working for a unit that you own, so you can give raises individually, replace the manager if necessary, and generally so that you can keep working with your subsidiary continuously no matter what happens. This means that you need to be pretty hands-on with managing them, but you have to do that no matter what.

Hope this helps!