Friday, May 25, 2007

Why You Should Ditch C++ For Java

In the 8 years I've been developing in Java, I've heard of numerous arguments about why it is better than C/C++. Some rave about the garbage collection that frees you from (most) memory management tasks. Others are swearing by the thread awareness of the language and the libraries. Or the design patterns that are elegantly embedded in its library implementation. Or the VM abstraction that makes it possible to run the same code in multiple operating systems. And of course you can always find the weirdos that mumble things like type safety and automatic bounds checking. These are all nice indeed, but it is something else that fills my heart with joy each and every time I stumble upon it.

Pretend for a minute that you make a living programming computers. I know, why would someone in his right mind do something like that, but bear with me. Let's also assume that for reasons unknown even to the Creator himself, you are using a development environment (IDE in geek-speak) written in C++. Suppose that while banging merrily at the keyboard you hit an IDE bug. Kaboom!

Segmentation fault. Core dumped.

Or perhaps you got a pretty little window on the screen that informs you that something terrible happened to your IDE and suggests to notify the proper authorities (that is, the IDE maker). After recovering from such a traumatic experience, you will eventually have to relaunch your IDE, curse for the Loss of Unsaved Changes and do them all over again.

Now let's assume you were using an IDE written in Java. Click, click, click: bug. But this time no kaboom. You clicked on some button-shaped thingy but nothing happenned. You click again, nada. The IDE is still there but something went obviously wrong. You call for help and your friendly sysadmin shows up. He digs up the IDE's log file and he shows you what happenned:

java.lang.NullPointerException
at org.eclipse.update.internal.ui.wizards.ReviewPage$TreeContentProvider.getParent(ReviewPage.java:181)
at org.eclipse.update.internal.ui.wizards.ReviewPage.getSite(ReviewPage.java:1370)
at org.eclipse.update.internal.ui.wizards.ReviewPage.access$29(ReviewPage.java:1367)
at org.eclipse.update.internal.ui.wizards.ReviewPage$13.run(ReviewPage.java:816)
at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:113)


What do you do? You just forget about clicking that button-shaped thingy ever again (or maybe for a day) and get back to coding frenzy.

The important thing to realize is that in both cases the same problem emerged. A reference or pointer to something was accidentally pointing to something else instead, and it was being forced to behave, perhaps a bit abruptly. After all, we should all be careful where we point to. It's the noble thing to do. But the impact of such an accident was fundamentally different. In the first case the operating system killed the process, while in the second case an exception was propagated up the stack. Both programs are multi-threaded and therefore capable of doing many things in parallel, yet the first one could not avoid having all its threads killed because one of them messed up. Oh, the cruelty! How would that make the other threads feel, I wonder. The Java program on the other hand, rightfully punished the offending thread (to make an example perhaps), while the others were left alone to go about their businesses. My guess is they all chatted quietly afterwards about it and everyone agreed that the grounded thread was a troublemaker, who got what she deserved.

The same thing happens all the time on server programs, too: big, heavy applications that serve legions of users. When the administrators are least expecting it, a stray pointer causes havoc. The service goes down, the call center is flooded with support calls and the administrator's pager goes nuts. That is for C++ server programs, of course. Java-based server applications go on serving people, even while a few threads get kicked in the bottom every now and then. (And in case some smartass mentions using watchdog daemons to restart servers: would you rather have a staff that worked via self-motivation or a staff that needed angry, big dogs to watch them while they do their job?)

So, in a nutshell, that's why you should not be using C++. Not if you pity the poor program's users, that is. Or its undeservedly punished threads. C++ is a hard, cruel language. Come and join me in the heavenly world of Java.

Wednesday, May 16, 2007

The Big Blue Blues

Bob Cringely has a two-part story on IBM's LEAN project. LEAN is a plan conceived by the executive team around CEO Sam Palmisano, to improve profitability by reducing costs. The idea is to offshore and outsource most of IBM's US-based operations to countries like India and China where it has been building up its presence during the last few years. The way this works goes like this: first of all, you pick the most expensive employees on your staff and you fire them. Then you make the remaining staff work overtime unpaid, to take on their responsibilities, so that customers don't start suing. Finally, you bring in new cheap labor to replace the ones who got the boot and hope they'll get the job done.

This is apparently the way you do business in publicly-traded companies these days. Product quality and brand value may go down the drain, but if such things please the stock market, then the executives can eventually cash-in their options and retire to Hawaii. The poor sobs that got the sack will be in a less advantageous position, unfortunately. Trying to find a job at their age is not something one likes to dream about. You see, the ones who get fired are not necessarily the ones with the larger paycheck. If that was the plan, the CEO would probably have to go first. No siree. Executive-types worry the most about having to pay pensions for their retired employees. So, instead of identifying the real blocks for increasing productivity, they just reduce costs and pretend that it's all well and dandy.

Apart from Cringely's excellent analysis, what is even more interesting is the comment section in his first post. Many anonymous IBMers have shed more light into the matter and also into the company's business practices of late. Underbidding contracts, mismanaging projects, lying to customers and 9 layers of management are the ones that stand out for me. The situation appears to be helpless. People come out frustrated, disappointed and in despair. Someone who used to work for DEC in the 80's said it was all too familiar for him. I have also been getting similar signals myself.

I have worked in an IBM project as a subcontractor for the better part of a year. My experience was rather good, all things considered, and I made quite a few friends there. This was a few years ago and the project was apparently a huge success for Big Blue. The team was hard-working, well-organized and included some very talented engineers. We were lucky enough to have probably the best project manager in IBM Greece's payroll, as I was told. And it certainly matched my experience. However, we were the exception. The word on the street was that IBM execution sucked big time. Virtually everyone admitted it. And not just project management, but other layers, too. I heard stories about constant quarrels in the team and lousy interactions with the customers. I know people who were fed up with the company and left. And based on multiple reports as well as personal experience, I wouldn't rate their engineering as first class.

The problem with 800-pound gorillas is their weight. Their greatest strength is eventually their doom.

You don't underbid if you are an 800-pound gorilla. That's common sense. Brand value is expected to be paid for. Startups know all too well how a slim profit feels like. If you miscalculate your expenses, you suffer. It's the risk you have to take to fight against the big boys. But startups have less fat than big firms. They haven't lived long enough to accumulate dysfunctional support layers that help run things but do not contribute to the bottom line. Big corporations can't afford not to make money to support their less profitable units. At least they can't be doing it for a long time.

Then there is the issue of mentality. On every successful project you have one or more champions. The people who are the stakeholders and carry the rest along the path to success. Big organizations have a tendency to dilute responsibilities among many people, without necessarily empowering them or giving them enough room to function. Eventually employees develop a public servant attitude and invest just the necessary effort for a minimally accepted outcome. If project managers were also architects perhaps it could work, but that is very rarely the case in my experience. Startups on the other hand are constantly running like there is now tomorrow. Continuously trying to outperform, outsmart, out-engineer their competitors in order to get a larger piece of the pie. Until they grow, of course, and become gorillas of their own, and age, stagnate and eventually die. Or maybe split up into many smaller groups that can be restructured as a startup again. Like what should have happened with IBM in the 90's, as one poster commented.

It's the same thing as what has already happened to Microsoft. And what will probably happen to Google in, say, 20 years. It's quite normal actually. But sad. And if you are trapped in there you might want to start searching for the emergency exit.

When I was graduating from college, I considered the worst aspect of working for IBM to be the dress code. I didn't wear suits at the time. As I found out, things have improved in that area. Unfortunately, virtually everything else has gone south.

Creative Commons License Unless otherwise expressly stated, all original material in this weblog is licensed under a Creative Commons Attribution 3.0 License.