N. Alex Rupp's Blog

TechEd 2004, Day 02

I don't know exactly what I was expecting from Steve Ballmer's keynote address this morning. I've never seen the man speak before, or heard his voice. In fact, I haven't even seen a photograph of him that wasn't a decade old. What I did not expect was for Mr. Ballmer to have somehow transformed into a spitting image of my former Governor, Jesse Ventura. They look alike. They speak alike. It threw me for a loop.

Mr. Ballmer has a very strong presence on stage, but it wasn't his presence that really drew my attention during his keynote. It was the contents of his message and, more importantly, the way in which he delivered it that most impressed me.

What I'm about to do might be a bit unfair, and I apologize in advance if I upset anyone, but the only other major keynote speaker from the IT industry that I've ever seen was Scott McNealy, who gave the final address at JavaOne last summer. The more time I spend here and the more I explore the differences between the Java and .NET communities, the more I wish I were going to San Francisco in June, so that I could make back-to-back comparisons while it's all still fresh in my mind. Last year Sun and Microsoft were still embroiled in a major lawsuit, and so of course Mr. Ballmer's speech this morning was more positive and constructive than Mr. McNealy's was last June.

But even so, Ballmer did not lash out against other technologies, or against Sun. He certainly didn't make the mocking of his company rival a central part of his keynote, as McNealy did last June. He kept an extremely positive focus, and stuck to community and technology-based topics throughout the entirety of his address. It was very relieving.

I'll get into the technical and business related contents of his speech in a moment, but first I want to make some important cultural and rhetorical critiques. Mr. Ballmer is a visionary, and he probably doesn't walk in the quite the same world as you or I do.

This became more obvious to me throughout the day. After spending some time in the trenches discussing ideas and technological considerations with different developers and vendors, I've come to the conclusion that there is still a great deal of bitterness toward Java developers among the .NET rank and file. What surprised me most was how the topic of Java, even among and between perfect strangers, always returned not to the technological flaws of our platform, but to the "jerk" attitudes of our developers.

I'll be the first to admit, my flaws are boundless. I've written and said some things in the past, particularly about Marc Fleury and about the Redmond giant, that were deliberately inflammatory and sensational to no constructive end. I know it's a bad habit to get into as a writer, and especially as a critic whose job is to interpret and not to cast judgement. This editorial style certainly doesn't make me a better person, so I've been trying to grow out of that practice. It certainly helps to have people I admire, like Richard Monson-Haefel, acting in an extremely courteous manner toward someone he's slighted. For that, Richard, I'm very grateful.

It's easy to demonize your opponent when they only exist on your computer screen, but it's another matter altogether when they're standing right in front of you. And the whole "tribe mentality" plays into it as well, as it does in software projects, as it did last June when Scott McNealy made his keynote and burned Microsoft. It isn't difficult to see how the rank and file Java developers might amplify this half-playful distain into raw contempt for the .NET crowd. But the "US versus THEM" Napoleon-complex mentality is a luxury we can no longer afford as a developer community. As an American citizen, I can definitely say that political events of the last year have given me pause to reconsider how I conduct myself in public, and especially how I regard and treat my competitors in the public arena. I don't hate these people—I have a tremendous amount of respect for them, even if I disagree with them on technical details.

Which brings me to the next part of my blog for the day. For the last year I've been flirting with the dream of bringing affordable J2EE technology to small and medium sized businesses, and of someday making it possible for small companies to buy affordable, enterprise quality software. That, more than anything, is the reason that I use, study and develop Open Source software. Sometimes I get frustrated by the high cost of deploying enterprise-strength web applications. I'm probably just trying to crack an egg with an axe, but it's the principle of the damn thing that I just can't shake. I'm a small player but I like to think big, and I admire other people with the same penchant. I'd like to be able to deliver big, even to small clients who share my unfortunate addiction to thinking big. What really bugs me is when people I know make tongue-in-cheek comments about how companies who can't afford to pay hundreds of thousands of dollars for J2EE's stability and features don't deserve it. I refuse to accept that only Fortune 500 companies deserve rock-solid code. This totally ignores the market potential and the importance of small and medium sized businesses, and doesn't do much for the reputation of the Java guy.

Today, I saw more evidence of that truth than I was prepared for. Microsoft's development tools are easy to use, easy to learn, and affordable. That is why .NET is so appealing to small and medium sized companies. According to Ballmer, over 50% of IT developers in the country use .NET. These people don't write code--they have forms and wizards for developing just about anything you can think of. When they do write code, they have development tools that actually force them to write unit and performance tests. And from what I can tell, they have tools for writing those as well.

The tools they've got coming out this year will probe their software for security vulnerabilities, and color highlight the areas of their code which they have not adequately tested, forcing them to correct the error before they check the code into the repository. Tools, to amplify their productivity. Tools, to tell you while you're developing if you'll have fatal errors at runtime, thereby easing the testing and QA process. Tools for performance testing components in ASP.NET web applications, to push multiple simultaneous threads through your software, to bootstrap an ASP runtime environment and use it behind the scenes to simulate a live runtime environment. JUnit won't even add a Multithreaded Test Runner to their core API. Tools to design web UIs, built directly into their ASP.NET IDE. More tools than you can shake a stick at.

In the United States, only the pharmaceutical company Pfizer spends more money on R&D than Microsoft does. They've embraced Agile development techniques in Redmond and before long the rank and file will catch on as wel—they will have no other choice. The tools are there to make Test Driven Development ubiquitous throughout the .NET industry. In the realm of tools and ease of use, Microsoft and the ecosystem of small vendors surrounding them have got us outgunned and outclassed.

All of this was running through my mind before Mr. Ballmer even finished his keynote.

BUT—we in the Java community don't claim to be the most approachable or user-friendly development platform in the world. Usability has never been the greatest strength of the Java platform, and I know we're making strides to overcome our deficiency in that area. As I attended various sessions on .NET technologies, especially one about developing web applications with ASP.NET, it became fairly clear to me that we still have a tremendous and important role to play in the future of enterprise computing, of persistent transactional object frameworks, of distributed component frameworks, of ultra robust application servers. We've got a good handful of J2EE app servers on the market already, and more are one the way from JBoss, Jonas and Geronimo. The licensing costs will fall by necessity, freeing up more spending for support and better feature offerings.

Microsoft does not seem to have an answer to EJB, or at least the developers I've spoken with don't spend much time considering distributed component architectures. They're still coaching developers to hand-write their SQL code—the very thing that drove me from ASP technologies back in 2000. "Sometimes it's better for performance to customize the SQL", a gentleman explained to me this afternoon. Agreed, but where is the option to have a persistence engine do the heavy lifting for me? I can always subclass a BMP object to do custom transaction stuff. When the customer decides to change to a different database on a different operating system (yes, it actually does happen) and they've got to rewire their library of data access objects, it will certainly help that the SQL queries are encapsulated into objects and not scattered throughout the application, but it won't save them if they've got 6,000 unique data objects in their system. I'm not saying this to be cruel, or to spit on ASP.NET technologies. It's just my perception. ASP.NET might not be the best tool for that job. Or maybe it is. If so, is it worth the risk of lock-in? If it's not worth the risk of lock-in, does that mean that Microsoft and its employees are all terrible and evil? Of course not. It probably just means we need a two-tiered market, and that things are the way they are for a very good reason.

It always seems to return to two crucial factors: the tradeoff between flexibility and performance, and the tradeoff between vendor lock-in and the inefficiency of committee-governed standards bodies. Is that what this whole long fight has really been about?

Enterprise scale technology is not always necessary. But when it is necessary, when a distributed component architecture is necessary, when you need a Component Transaction Monitor and common server-side component model, does .NET measure up? And if so, is it worth the risk of getting locked in? This is what I still don't know. Critics of Microsoft's MTS technology always return to the issue of vendor lock-in, of the open-ness of EJB as a server-side component model, of the ability of different vendors to implement the technology and compete with each other for performance, features, pricing, etc. If the Sun and Java community weren't as dedicated to sharing the wealth of ideas, of supporting non-profit organizations who want to compete in their CTM market, projects like Geronimo couldn't even exist.

I think that, out of respect for my boundless ignorance, I'll defer any further exposition on this topic until after I've spoken with some more .NET evangelists, specifically the ones who would know about .NET's distributed component architecture capabilities. Also, out of respect for the customers and managers who ultimately must make this decision, I'll just keep looking for the common ground, the higher patterns and the difficult questions, and leave the decision to the people who ought to be making it. Finally, out of respect to the engineers and developers on both sides of the fence, I'm going to try really hard for the remainder of the week to represent the "Java guy" as a fellow developer and not as an outspoken, embittered ideologue.

I will write about this rockin' hotel room, when I get a chance. Hope everyone's having fun out there ;)

Comments

• Persistence/EJB and .NET
  Persistence framework, yes .NET is lagging, but it has better potential due to the support of Attributes (declarative approach) to have much better frameworks. With ObjectSpaces (.NET v2) this lag will become shorter.
  EJB, look for .NET Remoting. Server Activated Objects and Clients Activated Objects, more or less present what EJB’s core ideas are all about.

  Posted by: khuziz on May 25, 2004 at 02:21 PM

• Persistance .net / Java
  Unfortunately I don't have any experience of EJB, however I do strongly believe the persistence model in .net is quite powerful.... but as will all great power comes great responsibility, I believe the problems we often encounter with vender lock-in due to poor data object design is more the fault of the developers and not the .net persistence model or platform as a whole.

  Posted by: jond on May 26, 2004 at 08:43 AM

• Great blog
  Some good points raised. Cheers.

  Posted by: rwinston on May 26, 2004 at 10:25 AM

• Napolean, Who me?
  Couple of issues, Your quote of 50% came across as fact. You start of by saying, "according to Balmer..", then "you" go on to say "these people ..". I do not want to go into what MS is doing with .Net, how it compares or even if it is all that you or they say it is. It may be true that Sun and Microsoft have agreed to disagree, It may even be that Mr. McNealy will propably joke about the detante come Java One. It doen not however mean that the basic permise of the idealogical battle that I am party to is over.
  If most of what you say was just about technology, there reeally wouldn't be a propblem, Microsoft would have lost long time ago. You point out how easy their wizards are. Its precisely those abominations that made me switch.

  I still remeber clearly, it was 1995. I got into this heated discussions about polymorphism and inheritence with my collegue. I was a Visual Basic programmer back them. I wondered aloud why I could not subclass a grid ocx and specialize its behavior so that all the code I copied and pasted could be encapsulated in the super class. It should not be done, object oriented coding is bad, its this and its that.. When these same folks are now doing object oriented coding!

  Microsoft tools are easy because they make assumptions about the world and about you. Their universe looks simpler because you have to make less decisions. Take a look at their CLR. They have designed it such a way that all languages have to implicitly or explicitly acknowledge the nature of reality Microsoft has modeled. My bone of contention with Microsoft is not about technology, its about the nature of reality. I bear the scars of many battles to prove it. I have worked with OS/2 (heck I still have one running on a 486!), I have done OpenDoc and Corba. And I have watched these technologies come under sustained FUD attack and wither. I watched Java under simillar attack during its infancy and still do.
  "Freedom to innovate" is a Microsoft byline. Having taught myself how to program, I quickly realized that software engineering is essentially an optimization problem. The variables you are trying to minmize or mazimize is however fuzzy at best, non existant at worst. The "ease" of Microsft tools is basically a local minima or maxima. To claim it is a global one is what caused me to become a bigot. Once I accept their world view, there is no knowing if a higher peak exists or a greener valley. Coversely, my world is damn difficult because in trying to climb to higer peak, I migh be just inches away from a sheer cliff. And you can believe me, I have fallen many times.
  It may very well be that the vast majority does not appreciate such risks. However I for one will keep chewing on Microsoft till they accept that the world is bigger and deeper than any one corporation or government or political party say it is. I chose the road less travelled. It has been humbling to see that there have been many who feel the same as I do. For all those who think that .Net Studio is easy. Once upon a time there was a book which talked about distributed objects as if its the second comming. Today, thanks to tools like Weblogic Workshop or Websphere App Developer or JDeveloper or Sun Studio or Jbuilder, I can build a N-Tier client server system in a heart beat. The ease does not not come from the application, it comes from the architecture. Thats something the dotnauts will never really get.

  Posted by: suhail on May 26, 2004 at 12:39 PM

• MSFT
  I think the things wrong with Java are:
  (1) Not enough marketing *
  (2) Lacks a good 'out of the box' experience

  * See, now to most people, marketing == advertising, and thats not true. Marketing is all about trying to understand your customers, and reach them with an effective message. Marketing is about coming up with products that your target market is going to want.

  There are 3 target markets in IT. IT managers, consumers, and programmers. I'd always gotten the impression that MSFT wants to get a lot of developer mind share. I think that slacked off a lot during the dotcom years. But by then MSFT had achieved total market penetration and everyone was developing for Windows, simply because everyone else was too. Because they got lazy, Java was able to get into the cracks.

  In that same time, I think they stepped up their marketing to consumers (waves hand 'these are not the crashes you're looking for'). And they also seem to have captured the hearts and minds of IT directors (noone ever got fired for buying IBM^H^H^H MSFT etc.)

  What is right with Java.
  (1) There's always an easy way to do something. Oh sure, you can muck around with XML messages and classpaths - or you could use RMI and Jars in the lib/ext directory.
  (2) Its easy to write good OO code. As in the above note, that doesn't mean its impossible to write bad OO code, but if you do, then that pain is self inflicted.

  When I switched over from Visual C/C++ and VB to Java, it was a sweet blessed relief. Like banging your head against a brick wall, it feels so good when it stops.

  Now, arguably, there are 'better' languages, Smalltalk (more 'purely' OO (Java is two languages, a language of primitives, and a language of objects, and apart from a few odd things with Strings and arrays, never the two shall mix)) and say Lisp (the very functional language). But, when I switched to Java, I had years worth of pent up OOishness inside, which was struggling to get out, so I bought some books, tootled around and churned out some awful code and learned the language quickly.

  People tell me that learning Lisp would be 'good for me' or something. But whenever I go to learn it and reach for those years of pent up pure functional programming... they're not there... Oh, sure, occassionally it would be nice to pass a method to another object, but as a general rule I avoid the callback way of programming, as it is a rocky shore on which I've seen many others code get wrecked.

  The same with Perl and other scripting languages. Inside me there is no pent up desperate need to use regexs. I use the methods on the String class and a LineNumberReader, between them they do just about everything I want for text manipulation. (And super fast too!) It doesn't matter so much to me that its much more readable, but thats a plus in its favour as well.

  Raw Performance? Java beats gcc compiled code in most of the benchmarks I've seen.

  Additional language features? Generics? Closures? (Pfft, just use an iterator) Typesafe enumerations? (Puhleeze - I was happy to leave those behind in Pascal. I introduced a guy to Java back in the 90s who was an old school Pascal programmer. He used to complain about not having enumerations - he couldn't understand how I could write code without them, but they're like global variables, the less you use them, the less you find that you needed them after all. For every use of enumerations, there was a better OO way of doing things)

  All of the above adds up to a good 'programming experience'.

  How does MSFT stack up?

  What MSFT *used* to do right:
  (1) Best help files evar, VB versions 1-5 (but especially from version 3 onwards). After that, worst help files evar. (!!!!!) (NB: VB 4 was worse than useless, but the helpfiles were still years ahead of anything else)
  (2) Build me an application wizards in Visual C. These were really sweet. The VB programmers used to think they were 'teh ubor' and could slap something together really quickly, but in VC you could just pull up a wizard, choose a project name, tick a checkbox whether it would be MDI or not, and *BAM* there you are, menus and everything! Sweet. Of course, noone ever used it that I know of, but it was still good for getting up and running really fast.

  What MSFT still does right
  (1) If I want to do some joins in SQL, the fastest way to get it right is to prototype the query in Access (and then throw away Access!! - do not skip this step!! ;-)

  What MSFT did wrong
  (1) They never grokked OO. Consider VB. You could add functions/procedures to your forms, and you could add variables to your forms. But your methods would be private, and your data would be public!!! Anti-OO at its best. Consider C++. Who did not cringe at all the ///// do not touch this ///\\\ very important secret squiirel macro stuff \\\\\ scattered liberally throughout your code??
  (2) They made the difficult things nigh on impossible. I had a huge advantage over other VB programmers, because I'd read Petzold, and knew the Win32Api. But this knowledge was extremely dangerous. you shouldn't really need to save your work before running a unit test in case the machine BSODs and you lose all your work.
  (3) They made some things easy which people should never have used at all (so many gotos, so few Larts). I have seen good code written with gotos (it was from an MIT graduate that learned to program before code indentation became popular - even with no indentation and sprinkled with gotos, his code was readable) - but most people should never have been let near them.

  Summary: MSFT has some good tools, on top of some really bad ideas. I don't know what the state of the help files in Visual Studio is. I haven't used .net, we've just had a .net fanatic move into our area at work, and he says it doesn't work on NT or 2000.

  There are some basic problems with their approach.
  (1) They want you to be locked in
  (2) They don't want you to be able to look under the hood.

  Contrast that with the openness of the Java core Apis - if I want to know what the deal is with runnable and Thread... I just go look at the source code.
  The big thing the Java Apis are missing is a prolific scattering of examples like VB.
  Java itself could do with a simple screen builder, to give a better 'out of the box' experience, but there the VB advantage is that the language and IDE are bundled. Whereas Java chooses to let you pick an IDE that suits your tastes (and they all produce truly awful screen building code).

  So in conclusion, as an expert programmer, I'd much rather be able to look under the hood. Java may have displaced (to some extent) C++, but it requires a fundamentally different approach before it displaces VB (to compete here it needs to target the lowest common denominator - the programmers who use VB because 'real' languages are 'too hard').

  Posted by: rickcarson on May 26, 2004 at 06:33 PM

• It's components are what rules the roost
  If you throw out the tools (VS.Studio) or certain business practices, the fact is that MSFT has a large amount of dev mindshare for a similar reason why Java, Perl and C on Unix do. And that is the availablity of libraries/components that make it easy to develop applications that users want.

  This is particularly true on the desktop, which was all-but completely lost in the dot-com era. And that had more to do with Java and Linux success than whether Java was really better than VB.

  The advent of Web Services allows that to change.

  And .NET makes it every easy to hook stuff together in particular office apps.

  This is one area, where Java really lags behind and I'm not talking about the usual Swing is slow, ugly and hard to use issues.

  It's about the fact that the JRE is still not nearly available as it should be. The fact that it's slightly smaller than the .NET CLR is a small help when the difference is that the JRE is 14 Mb an .NET is 20 or in that range.

  It's also about the fact that we don't have a simple way to utilize the browser to display HTML from within swing.

  This is why I'm really following SWT. It's not about SWT vs Swing in terms of native look & feel. It's about the fact that SWT enables you to hook into Office apps if you're on Windows. It's about the new browser component that will allow you to include good HTML rendering into your Java client apps.

  And the real kicker - if I know this has to go on Windows - I can use GCC's Java compiler on Windows and get an old-school EXE. No JVM or CLR needed. Yeah, you have potential versioning problems - but guess what - if you simplify your app, this is much more solvable than you think. Look at Mozilla Firefox as an example what simplification can do for you in the maintainence area.

  On a cultural note, the MSFT people generally are unified in vision, there's not the internal cultural war (or at least it's much smaller) that happens in Java & Open Source land where we waste even more time bagging on the other guy about why his web app framework sucks even more than mine, even though neither one of ours will be finished before 2050 because we can't learn how to work together.

  Posted by: mwilcox on May 27, 2004 at 12:42 AM

• Hang on a minute Napolean!
  Hang on a minute..... If you didn't like the wizards and lack of OO and subclassing in VB you should have switched to VC++. It's like me complaining my spanner won't undo a screw when if I looked in my toolbox I had a screwdriver sitting there waiting, you were using the wrong tool.

  Just as today if you don't like the .net classes extend them, change them, or write in unmanaged code don't knock the classes that suit 90% of the people 90% of the time.

  I think the reason you have been stuck with VB wizards is because you didn't have the knowledge or skills to work around them.... not to say that's a problem, it is exactly why people like MS dev tools because they allow people to write apps easily. However they also afford developers a lot of power and versatility including the tools to do exactly the stuff you couldn't, if only you'd picked the correct tools.

  Posted by: jond on May 27, 2004 at 03:28 AM

• Hang on a minute Napolean!
  I did move back as a matter of fact, to small talk ;-) Having said that, you make the arguement for me when you say, "because you didn't have the knowledge or skills to work around them". I will confess to a complete ignorance of what happening with the dotnaut communities today. However, I do think you misunderstand me. The general thrust of my arguement is that if at some point Java became dogmatic, even about how something aught to be extended, I would leave. I do think that java communities are the least dogmatic around, witness the multiple implementations of all sorts of apis, patterns and blueprints. Now 90% sounds a like the majority but when you count the 10% left you will find that its a huge number of people. I just don't buy the argument that Java tools are complex and MS tools are easy. Take my current problem. It required four databases, two application server and nearly eighty cmp entity beans to solve. Give eighty beans, you can imagine the number of support and related classes involved in the system. The system was scoped, built , tested and deployed by just two analyst/developers and a tester over a period of a year and a half . The funny thing is that one of the developer had only a few months of java experience. In fact, most of our time was taken up by analysis of the doman (financial risk) and not the actually code. Even five years ago, such an undertaking would have taken more time (or people). The system has been in production for nearly six months now, the users are happy. The two of us are happy since we really did not split any hairs or try and over engineer the system or anything like that. The requirements dictated an N-Tier and we pretty much generated one. Most of the architecture came out of the box and the rest of it was just common sense. Its exactly why people like enterprise java dev tools because they allow people to write architecture easily. Naturally, if you don't like the architecture, you are quite free to invent one.

  Posted by: suhail on May 27, 2004 at 07:16 AM

• Persistence/EJB and .NET
  Rumour has it you'll have to wait for ObjectSpaces. Formal release has been postponed to the Longhorn timeframe (probably because MS want a universal data access layer and they want to get it right first time). You'll still be able to use betas but don't expect it to ship as part of the Whidbey framework.

  Posted by: garethr on May 28, 2004 at 06:39 AM

This work is licensed under a Creative Commons License.