Clash of the Titans

IBM and Microsoft are squaring off for leadership of Enterprise development. Rational (IBM) is ramping down in fact on .Net support (they’ve been paying lip service only for quite a while), and Microsoft’s Ballmer (“Developers, developers, developers”) is positioning VS 2005 on the high end to be just what Enterprise developers have always needed.

Who wins and who loses here? And how does this affect the existing industry alignment (Microsoft vs. Everybody Else)?

News this week

Historical Background

Over the last few years, IBM and Microsoft have co-existed in relative
peace because they've concentrated on different markets. In the last year
or so, though, there's a definite "ain't enough roon in this town for the
both of us" feel to this landscape. IBM, whose stronghold has always been
big, big business, has made quite a bit of noise about breaking into the
SMB market. Microsoft, on the other hand, has been working hard on
building enterprise features into Whidbey, its next development platform.

The last time IBM and Microsoft really squared off against each other in a
meaningful way was when OS/2 and Windows were duking it out. In that
battle, IBM appeared to go quietly into the night, preferring to harvest
the more profitable pastures of hardware sales and high-margin services.
As the dust settled, they found themselves owning some big-company high
ground (good), but with very little platform or developer penetration (bad).

This was the point where they jumped big-time into Linux and Java support,
which made a good deal of sense for them. After all, they'd be able to
make a good living on services following this strategy. In addition, if
they couldn't own developers, they wanted to make damn sure that Microsoft
didn't either. Snapping up Rational added more fuel to this fire, fitting
well with the Java development and big-business focus. The final piece of
the puzzle for them was Eclipse, started as an IBM-sponsored open-source
Java development IDE. Ironically, in order to really woo the open-source
community, IBM had to relinquish control of the project, which has gone on
to be wildly successful.

So, IBM finds itself with a strong enterprise presence and strong ties to
Java and open source development. They have, however, no direct control
over a big-time language, OS, or IDE. They have an app server and a
database that are both respected but certainly not dominant. Finally, they'
re still outside looking in at the SMB market.

Microsoft, on the other hand, has owned the SMB market for as long as
there's been one, and they continue to advance their well-respected IDE.
They own the IDE and languages (C#, VB.Net), and they're chasing the
problem IBM had with eclipse: people are afraid to commit to platforms
owned by one vendor.

Microsoft has been vulnerable on the hobbyist programmer front relative to
open source platforms like LAMP (Linux, Apache, MySQL, and PHP/Python).
These platforms are free and it's easy to find cheap hosting with this
environment already set up, creating an uphill battle to attract weekend web
warriors.

In the enterprise, Microsoft has been losing to Java again because people
are afraid of vendor lock-in. Sun, HP, BEA, IBM and others have been quite
successful convincing big-time IT tha the only way to ensure scalability is
with a J2EE software stack on *nix. The apparent portability from one
vendor to another has also helped create the perception of safety.
Microsoft just hasn't had an answer to this, and going proprietary with .
Net didn't help their cause at all.

Today's Playing Field

Looking at this week's announcements, IBM can clearly be seen to be
retreating, while Microsoft is in attack mode. Microsoft's biggest
vulnerablility continues to be its single-platform direction, though there
are some signs of softening (cooperation with Sun, discussions with RedHat).
If Microsoft would publicly get behind cross-platform .Net efforts like
Mono and Mainsoft, I think there would be a big boost to .Net adoption as
companies see vendor and platform options become available.

IBM continues to shoot itself in the foot by taking on Microsoft directly
and even by poking at its most loyal developers (IBM created an uproar in
the Java community by showing interest in PHP; Java developers felt that
this was a show of no confidence in Java). Product offerings from IBM
continue to be disjointed and confusing, contributing to the perception
that IBM's products exist only to sell IBM's services.

The wild cards right now are vendors like Oracle and BEA, who have been
reasonably quiet in recent months. BEA just began a major campaign to
launch their next-generation SOA platform, which claims to be the optimum
platform for SOA regardless of language. Oracle is still digesting
PeopleSoft, but appears to be interested in taking the enterprise from the
applications front rather than the development front.

Predictions

As IBM's grip on enterprise development loosens, support for Java will
become more fragmented. The strong, widespread support for Eclipse ensures
that Java is in no danger of disappearing any time soon, but there's also
no sign of any unifying force for Java as a whole.

Although UML has never been really dominant (even IBM says that only about
6% of developers use UML), Microsoft's continued upward pressure will spell
the end of UML as a mainstream modeling tool. Rational will become
marginalized as a boutique vendor.

Finally, the big one. As BEA continues to position itself as the platform
to run the enterprise on regardless of language, they will integrate .Net
CLR support into WebLogic, perhaps through a derivative of Mono. This is
viable for them because they're already acknowledged as a leader in the
J2EE space, and nobody seriously considers Microsoft to be an enterprise
application management platform.

Although some have considered the possibility of a Microsoft/BEA
acquisition, it's actually more valuable for Microsoft to have BEA
establish .Net support while still independent. As an independent company,
BEA can relieve the single-vendor lock-in problem that's limiting Microsoft
today, facillitating much more rapid .Net adoption in the enterprise. As
the first application server to support J2EE and .Net, WebLogic will surge,
forcing Websphere and JBoss to follow.

There you have it - remember, you heard it here first!

Introducing Predictions

The high-tech field has never been at a loss for news. In my years as an IT professional, I have seen the change from mainly print-based (magazines, newspapers) to mainly electronic (newsletters, web sites). As distribution became cheaper, the volume of news has exploded, to the point where the volume of information that's available is overwhelming.

Though we now know more than ever before about what's happened, we're in no better position to predict the future -- until now. I've always had a talent for spotting trends and momentum in our industry, and I'm going to let you in on what I'm seeing. Watch this space for news you can really use.

Beware of long answers

I think everyone's experienced difficult conversations in which you have to drag information out of someone. If you've ever had any training or experience in requirements gathering, sales, or other interviewing, you've also learned about open questions vs. closed questions. In my experience, this is almost always focused on drawing additional conversation out of someone who doesn't want to be conversational. There's another side to this phenomenon, though - the person who takes a yes-no question and fires back a wilting soliloquy.Some people call this doubletalk. Some people call it rambling. Many people don't even realize it's happening -- it's the long answer to a short question.

I've begun to pick up on this more quickly than I have in the past because I'm seeing it in a few people on a regular basis. I can now spot the "long answer" almost immediately, just by paying attention to the nature of the question. There are some questions, of course, that should be able to be answered in one or two words ("Yes", or "This week."). When your answer doesn't fit in that sort of box, it stands out vividly.

I've seen two forms of the long answer, and these can be difficult to tell apart. The first is just rambling. This detracts from effective communication, but it's not really too harmful. You can identify this answer because there is actual information in the answer -- it's just spread out across a whole lot of useless dialog. Watch for this from engineers who provide exhaustive detail when it's not necessary (if you're an engineer, pay attention to your own answers - it's easy to do this).

Thei second form of "long answer" is true doubletalk or evasion. This is best detected by remembering the question that was asked and trying to match the answer to the question. If someone manages to change the subject of the conversation in the first three words of their answer, they're deflecting attention from the original question. You can sometimes spot these in advance of the actual answer, because the question will demand a commitment in the answer:

  • When will you be done?
  • How much will it cost?
  • Have you documented the requirements?

The classic form of doubletalk is the political debate. Politicians are well known for their ability to talk on and on without saying a thing. Though it's less commonly recognized, this sort of thing happens all the time in business. When it's excessive, it's easy to spot, but very often, it escapes just under the radar. Again, keep the question in mind as you're listening to the answer, and see if the question is satisfied.

In order to become attuned to the "long answer", try watching for it in other people's conversations, and then watch for it in your own answers. Here are some occasions that may yeild examples:

  • Staff meetings.
  • Sales calls.
  • Job interviews.
  • Design reviews.

Armed with a little knowledge, you can make a lot of sense out of the context of some of these conversations, and the results can be enlightening!

Process isn’t just for “normal” projects

I've been working through some interesting process issues with my employer's CTO and head of Product Management. The thrust of these discussions is that we've revised our Product Planning and Product Development processes, and I'm currently working on documenting what we've agreed upon. No sooner had we come up with a plan, however, than a "highly important" project sprung up, prompting discussions about suspending parts of our process because this project was so important. I've managed to stop my head from spinning long enough to gather some thoughts....

Origin of Process Changes

I've grown my current development team from nothing, and grown our process along the way to fit the organization. Our informal process guide has always been "just the right amount of process for our needs... and nothing more." In our most recent revisitation of process, I worked with our CTO and Product Manager to address schedule variations due to requirements problems.

In short, we were entering a release with only the most vague sense for requirements for features in that release. In the past, this had resulted in schedules not being met because we didn't really understand what we were supposed to build until we moved a portion of the way through the release. I'd suggested better requirements a number of times (citing Joel Spolsky's excellent guielines), but this was written off as too much work.

Prototyping, it was agreed, would be the best compromise for our situation, allowing us to build out more detailed requirements iteratively. We tried this in a mini-release, and though we had some minor problems, it was deemed to be generally workable. A side effect of this process is that our release date couldn't really be known until we moved through about 1/2 of the release. Prior to that, we had a target and a +/- range for our date, but nothing one could take to the bank.

Screeeechhh!!!

It was about this time, of course, that the Important Release reared its head. We needed to figure out a date for the release *right away*, which was the first violation of our process. Nevertheless, I came up with a date based on similar work and similar releases we'd done in the past.

The date wasn't good enough.

Thus began the further erosion of process: "why can't we skip parts of the process and speed up the release?" "I know this isn't our normal process, but this isn't a normal release -- this one's *IMPORTANT*".

There was clearly a whole raft of concepts that just never managed to lodge securely in the nooks and crannies of these executives' minds. These are a couple of pretty smart people, so I can't chalk this up to lack of cognitive ability. There's something here that these guys really don't get, and I can't account for it.

The Missing Link

In the spirit of "we hold these truths to be self-evident", I'm adding here the rationale I've used to establish process. It seems to make sense to me, but as my recent experience has shown, it can't be taken as a given that this makes sense to everyone. I've seen this widely chalked up to "some people don't get it", and I have to echo that sentiment at this point.

Our software development process, like most, is designed to move us through a release as expediently as possible. It's not my habit to put process in place to make us go more slowly. Unfortuneately, this is a nuance that's frequently lost on the casual observer. Process, it's felt, is overhead. Cut the process, and you'll go faster.

Cover of

Steve McConnell's Rapid Development has a great passage about a software team from Ernst and Young who attended a programming contest and used process to great effect. They appeared to get out of the gates more slowly than everyone else, but their process made their progress so reliable and relentless that they quickly overtook everyone else. They ended up finishing second because of a breakdown caused by skipping part of their process! (They ended up using the whole process at the next event, and won it).

If process didn't help us, we wouldn't use it. Therefore, any process we've got is here because it makes us go faster. Simple idea, but frustratingly elusive when it comes to getting non-developers to internalize it.

I tried another example with seemingly little effect. Imagine someone who spends lots of valuable time coming up with a disaster recovery plan, and then when a disaster hit, the first thing they do is reach for the disaster recovery plan and chuck it in the trash. "I don't have time for a plan," they'd say -- "We have an emergency on our hands." Most people, I think, would say that they deserve whatever fate befalls them.

Not so with a software development process, though.

I'd like to hear your impressions and ideas. Register and post your comments if you've dealt with this.

Enhanced by Zemanta

System Admin checklists

Last week, I had an interesting discussion with my Sys Admin that left me boiling a bit. I ended up needing to find an article I thought I'd bookmarked a long time ago to prove a point to him, and ended up having to search to find it. This is another "gem" you'll want to keep handy -- if you're a Sys Admin, this is a must to read and understand, and if you're not a Sys Admin, it really helps cut through BS at those times when you feel that things just shouldn't be working the way they are.Our Sys Admin is the nicest guy in the world, but to say that he's disciplined would be to do a great disservice to the term. In fact, he's a "squeaky wheel" guy, addressing issues just as they're starting to get really annoying, so my conversation with him shouldn't have surprised me. Nevertheless, I was surprised to learn that we had not, to date, been monitoring the event logs on our Windows servers. At all.

After I turned three shades of purple, I tried to express my amazement that you can't get software to monitor event logs free in a box of breakfast cereal. What I really wanted to have handy, though, was an article I'd read years before explaining very simply what a good Sys Admin should do daily, weekly, monthly, and so on. I just knew that monitoring event logs was in there.

I ended up spending a few minutes trying to dig this up, but I finally found it again: NT system administrator's checklists

Greatest Windows tool set of all time

Think you know what I'm talking about? Read on to find out what I think, and be sure to register and post your comments if you think I'm out to lunch!I've always been a fan of Vince Lombardi's "This is a football" message -- you can't be successful at the hard stuff if you don't get the basics.

Windows is magnificently complicated. That it appears simple sometimes to some people is a mark of its success. It's a miracle that some of the people who use Windows are able to do so -- you've met these people, too, and you know what I'm talking about.

One of the side effects of Windows shielding us from this complexity, though, is that we often have to deal with black boxes when debugging problems. There's an awful lot of the Windows iceberg that we never have to look at, and can't -- even when we want to see it.

In this spirit, I've got to cast my vote for Sysinternals tools as the best ever. Never mind that they're free. They also just happen to the best tools I've ever seen to get to the bottom of what's really happening under all the fluff we call Windows.

Armed with these tools, you no longer have any excuse to not know what files are being touched by which processes, which processes are writing to the hard disk, and so on. As with any tool like this, you can easily lose yourself in the details, so you have to have enough grey matter to interpret what you're seeing.

The right tools mean never having to say, "I don't know..."

Don’t underestimate LAMP

I've recently seen an increasing amount of discussion about the LAMP stack (Linux+Apache+MySQL+PHP/Python/Perl) -- specifically, as an alternative to the traditional Java-based development stack (app server+enterprise DB+J2EE). I'n a technical landscape that tends to be polarized around Microsoft vs. Java, LAMP is quietly gobbling up a lot of ground.Open source "hit the radar" with Linux a few years ago. Apache has been the dominant web server platform since the mid '90's. The rest of the stack (MySQL, PHP, Python, Perl) has been seen as a nice set of tools for hobbyists and prototype work, but wasn't generally regarded as a serious toolkit for production development.

People are looking around and seeing that's no longer true.

I've been using PHP since I discovered PostNuke (see Whaddya got under the hood?) a few years ago. At the time, I admired the ease with which static web content could be mixed with scripted content. It had the same appeal for me for web development that Visual Basic always had for Windows development -- you could get started in no time flat, and although popular wisdom held that you wouldn't want to use this tool for anything serious, I could never seem to quite find that point where I completely ran out of gas.

Over time, all these tools have matured, to the point where it's pretty foolish to dismiss any of the LAMP tools as amateur-grade. There simply aren't too many critcal capabilities you can get in "enterprise" software development tools that you can't find in the LAMP stack, too.

The two shocking realizations that (1) these tools are for real, and (2) they're wresting developer mindshare away from Java and/or Microsoft stacks are hitting some people pretty hard. In the last week or so, I saw an article on LooselyCoupled.com entitled J2EE: No longer required. This article was mildly interesting, but the real eye-opener for me was when a link got posted on Slashdot and generated a literal firestorm of resistance from the Java community there. Since then, I've seen some additional aftershocks (What's so special about PHP?) that indicate that the rumbling hasn't stopped.

It's been pretty telling for me to watch the reaction of some of the J2EE community to these discussions. Objectively, I wouldn't have expected this much uproar. After all, most of the LAMP stack is trying to accomplish goals that are compatible with Java's: platform independence and developer productivity. LAMP is compatible enough with Java that there's a vendor called SpikeSource that's putting together a certified development platform that they call a LAMP and LAMJ stack.

At the end of the day, I've got a lot of respect for the LAMP stack and LAMP developers, because my experience is that these people tend to be a whole lot more focused on acheiving an objective through the most efficient means possible rather than getting wrapped up in a holy war. As a development manager, that's what I like to hear.

Generate web service stubs from WSDL

In most web services projects, you wrap existing software in a web service and publish a WSDL to define the services available. But, consider going the other direction -- you've got an existing web service definition, and you want to build sofware to perform to that specification. Here are some ways to get started pdq.

WSDL to .Net

I saw this tip first in a posting in a Joel on Software forum. One of the built-in tools in .Net is WSDL.EXE (look in the SDK folder in your Visual Studio.net install). Normally, this tool is used to generate web reference mapping code so that you can use a web service in your application, but it's equally happy to create "stub" code for you given an existing WSDL.
Notes:

  • Syntax looks something like this: C:Program FilesMicrosoft Visual Studio .NET 2003SDKv1.1Bingenerated>..ws
    l /server /language:vb {your WSDL URL here}

  • type WSDL.EXE with no params to get help
  • the language param can be used to generate code in C#, VB, or VJ#
    (language = CS, VB, JS, VJS)

WSDL to Java

Although I haven't played with this (yet), I'd be remiss if I didn't point out the Apache Axis Project, which does much the same type of thing for Java. See http://ws.apache.org/axis/cpp/winuser-guide.html for a short write-up on getting started.

Google tricks

Knowledge is power. As you can see, I like RSS for news. For on-demand answers, Google's been the best show in town for a few years. Even experienced Google users, though, don't know some of the capabilities available there. You may stumble on these eventually, but wouldn't you rather have your bag of tricks ready when you need it?Google's philosophy has always been to keep its front page neat and clean. They're the anti-Yahoo, and it shows. I've heard there are even people who count the number of words that appear on the front page and ding google if it gets too wordy.

For the most part, this is a good thing. Google is a search engine, and they know it. Stuff that isn't an important part of their main product isn't featured on the front page. The only bad part about this is that it's easy to miss some of the other neat tools available from Google.

To get a sense for what's there, take a look at their about page. It lists some of the most important capabilities, as well as linking to the main "new and exciting" tools. Note the desktop search link -- you've probably heard a lot about that recently.

Don't leave this page without checking out Google labs -- this page shows the stuff that's just about ready for prime time. The scholar search, for instance, looks pretty interesting -- a capability that clearly wasn't there before.

If you run a web site, you'll probably also want to look at the "For Site Owners" topics to learn about getting your site to show up in Google searches.

Happy Googling!

RSS Content Syndication

I'm a news junkie. I've always subscribed to a variety of IT magazines, and over the years, it's really helped me to stay abreast of developments. Staying up to date on what's new can take a lot of work, though. There's a lot of information available if you want to hunt it down, but instead, why not have the information come to you?

Many web sites now offer XML-based content syndication that allows you to see headlines as they appear, and link to content if it looks interesting. The syndication techcnology is known as RSS (really simple syndication), and although it’s been around for a while, it’s just now starting to catch on in a big way.

RSS Background

I first saw RSS three years or so ago when I began using PostNuke (see “Whaddy got under the hood?”) as a development portal. Its standard install has always had a link in the page footer that said something about using “backend.php” to syndicate news. I was curious, so I checked it out. It turns out that this page delivered RSS version 0.91 content syndication – headlines from the web site in XML form.

Further investigation showed that there were some primitive tools emerging that would read these feeds. PostNuke, in fact, had (via add-ons) the capability of using these feeds to display a block of headlines from sites like Slashdot and CNet. At that time, there weren’t too many sites offering RSS feeds, and you could expect to do a little hand work if you wanted to consume these feeds.

The history of RSS syndication reads like many web standards – there are a few popular versions and several more abandoned offshoots. The original RSS was introduced as 0.90 by Netscape. A refined version, 0.91, was promoted by UserLand Software, and was widely adopted as the first mainstream RSS format. Several other 0.9x standards were published, but none really usurped 0.91. Finally, a 1.0 release and a 2.0 release are both based on RDF (Resource Description Framework), though 2.0 is by far the more popular. Of this multitude, most feed you’ll find these days will either be 0.91 or 2.0, and most readers can handle either. I’ve included a couple links at the end of this article that you can follow for more background.

RSS Technology

All RSS feeds are XML-structured documents (you can often spot links to RSS feeds on web sites by looking for the [XML] logo). If you take a look at the raw XML, you can see the general idea. Don’t dwell on the XML, though, because in the next section, we’re going to look at applications you can use to read RSS feeds.

<?xml version="1.0" encoding="ISO-8859-1" ?>

<!DOCTYPE rss (View Source for full doctype...)>

- <rss version="0.91">

- <channel>

<title>AppDev</title>

<link>http://www.appdev.info/</link>

<description>PostNuke Powered Site</description>

<language>en-us</language>

- <image>

<title>AppDev</title>

<url>http://www.appdev.info/images/logo.gif</url>

<link>http://www.appdev.info/</link>

</image>

<webMaster>webmaster@appdev.info</webMaster>

- <item>

<title>Whaddya got under the hood?</title>

<link>http://www.appdev.info/modules.php?op=modload&name=News&file=

article&sid=4</link>

<description>Just in cast you're wondering what makes AppDev go,

it's powered by a Content Management System (CMS)...</description>

</item>

- <item>

<title>Tip: building connection strings from scratch</title>

<link>http://www.appdev.info/modules.php?op=

modload&name=News&file=article&sid=3</link>

<description>Here's a tip posted by someone on the VB-DATA list.

It's already come in handy ...</description>

</item>

</channel>

</rss>

RSS Readers / using RSS

There are a number of applications available to read RSS feeds. You can scare up dozens of choices by searching for “RSS reader”. The basic functionality you’re getting is formatting of the XML feed, but a decent reader will allow you to set up a number of feeds and keep track of the items you’ve read.

Here’s a screen shot from SharpReader, my current favorite. One of the nice features about SharpReader is that you can set it up to poll for new stories and notify you when they’re posted with a little IM-like box.

Who’s got feeds?

As I mentioned earlier, there’s a very good chance these days that your favorite web site will have an RSS page. Here are a few popular sites that you may want to monitor to help you stay abreast of development technologies.