If You Build It, They Still May Not Come

In the early '90s, I had a nasty run-in with that harsh reality. At the time, I was the Manager of Architecture at System Software Associates, which was, in its heyday, the world's largest AS/400 software company. We sold more in BPCS licenses than any other AS/400 software package in the world. And my boss, the owner of the company, had a vision--to bring a GUI to the AS/400. And he passed that vision on to me, and it was good...

And thus came the Assistant products, a suite of powerful, graphical client/server applications that allowed end users to perform the normal green-screen tasks using a fast, intuitive GUI instead. Our pride and joy was the Formulation Assistant, which allowed you to drag and drop materials and operations onto a multi-level bill of materials and routing (a bill of materials specifies the components or ingredients for a product, while a routing tells how to make it), visually building the entire manufacturing process sheet from start to finish. You could build multiple versions, comparing them for time and costs, and then choose one to upload back to the AS/400.

The entire formulation could be viewed on the screen with colorful icons, and you could zoom in or out as needed. The comparisons could be graphed as bar charts or line charts or whatever you needed, and you could even print them on your local printer. Not only that, but the package was released simultaneously in seven different languages, with full help text on every panel.

This was the next generation of software for the AS/400!

Unfortunately, the current generation of AS/400 customer had no use for it. While they all oohed and aahed at the demonstrations, when it came time to pony up the bucks, there were inevitably reasons against it. For one thing, it required OS/2, which was not exactly the apple of everybody's eye. Even though OS/2 was at that time far superior to anything from Microsoft, it required a big, bulky PC, and it turns out that when you try to sell software to a manufacturing company running on a slender profit margin, you can't assume that they'll replace their cheap, durable green-screens with a bunch of expensive, temperamental PCs. (This is something all software manufacturers would do well to remember: In the Small-to-Medium Business market, the cheaper the PC that will work with your product, the better chance your product has.)

Also, while they saw that the product was "neat" technologically, they were hard put to determine exactly how it would save them money. Sure, they could graphically create a bill in one third the time they normally did. But if they created only one or two new bills a week and it took George about three hours to do one, what were they really saving? At the most, 300 hours of George's time a year? And old George was only making $22.50 an hour, so the fact that the new PC required to run the product cost nearly $3,000...well, that all but shot the deal from the get-go.

Our other products fared similarly. And, while we sold some and the people who bought them were happy, our misunderstanding of the needs of our end users caused us to over-estimate the market, turning a tactical success into a strategic failure.

And the funny thing is, I still remember that project with some fond memories. We were a smallish group, and we did things nobody had done before. There were no ground rules for what we did; we had to make them up as we went along. And (apologies in advance to anybody who gets miffed by this) this was in the day when bugs were expected to be fixed before the product shipped. We actually had zero defects on our products when they went out the door, and this included things like memory leaks. Not only that, but the product was expected to ship on time, on budget, and in seven languages simultaneously. And we did it!

What a rush.

And yet, no matter how much we patted each other on the back and celebrated on release day, the truth of the matter was that we had created a product that didn't have a market. We built it, and nobody came. If you make a product and nobody buys it, does it make a sound?

So What's the Point?

You're probably wondering what the point of this ancient history lesson is. Well, it has to do with not one, but two of IBM's recent initiatives: SWT and ICT. These two projects couldn't be more dissimilar, yet they share some rather disturbing traits with those Assistant products from long ago.

The Software Widget Toolkit (SWT) is a subproject under the Eclipse umbrella. It's IBM's GUI toolkit for Java. Much like JTOpen, which is the package that allows Java programs to communicate with an AS/400, SWT allows Java programs to create thick-client graphical applications, applications that are supposed to rival the look and feel of native applications.

Those outside the iSeries community may or may not have heard of Eclipse and SWT (although given the hype SWT has gotten of late, you'd have to be a hermit to code in Java and not hear about SWT). However, since SWT is the base GUI for Eclipse and Eclipse is the fundamental architecture underlying all of IBM's new generation of development tools on the iSeries (including WSDC and all its relatives, such as WSAD, and all its components, such as WebFacing), then you, good reader, are going to be affected by this in one way or another.

On the other hand, IBM Community Tools (ICT) is very iSeries-centric. ICT for the eServer was just released to the public for what I can only describe as a sort of uncontrolled alpha test. Those of us who heard about it actually got our hands on it on a weekend (just recently, in fact), and, boy, did we have a field day.

Different, Yet the Same

As I said, these are very different undertakings. The SWT project is a largish subproject under the even larger Eclipse project. Many of the developers on the SWT project have 10 or more years of experience, and many of them come from Object Technology Incorporated (OTI), the nice folks who brought you VisualAge for Java, among other things. The project is under close scrutiny by a large audience and has been alive, in one form or another, for 15 years or so. SWT has grand strategic goals, lots of interesting (if informal) documentation, and more hype than you would imagine for what seems at first glance to be a pretty esoteric project.

ICT, on the other hand, is an internal IBM project just a couple of years old. The average age of an ICT project member is considerably younger than that of an SWT member, many of the ICT team being recent graduates. The project had never seen anything other than IBM internal use before that fateful weekend a little while back, and there's no real game plan for development, no documentation, and no formal reporting mechanism to speak of (although there is a newsgroup!).

Very different projects, as I mentioned. And yet, they have some important similarities:

1. Both are just coming into contact with the iSeries community. Until now, they have been esoteric or internal, and in neither case has anybody really tried to use them for mission-critical business applications. (The SWT people might argue, but their primary deliverable to date has been development tools, and whether they like it or not, development tools are a little less mission-critical than order processing when it comes to running a business.)

2. Both are populated with very passionate people. The developers for both projects have a strong attachment to their respective products. You get the idea that this is not just a day job for either group. Unlike the good old maintenance programmer who has just written his 37^th master file maintenance program and isn't too concerned about whether he uses a MOVE or an EVAL, these folks deeply care about the individual lines of code, not to mention the overall architecture.

3. Both groups have some serious views on the intrinsic value of software. By this, I mean that both will tell you that code is either "right" or "wrong" because of certain built-in characteristics. For example, code written a certain way is "scalable," and that makes it good. Code that is not scalable is bad. The "way" that determines the scalability depends upon which programmer you ask and which references they use, but the "way" is not subject to dispute (this gets especially interesting when two programmers with different "ways" get to arguing). There are other such attributes. For example, code size is becoming an issue again, if you can believe it. I haven't heard that particular argument since we stopped burning code onto ePROMs. There is no way to contest these evaluations, and arguments to the contrary are seen as attacks.

4. Finally, neither team really understands what determines software quality in the world of business applications. As I stated earlier, the quality of business software is directly proportional to the number of customers who buy it. (Fanatics on either side of the Microsoft issue need not apply here, since software prepackaged with a computer is not "sold;" it is "bundled", and that's a different issue--one I'll discuss in a later column when I talk about the most recent IBM offerings.) More important, though, is this philosophy among the developers that they know what's best for us and that we, as customers, better not argue with them. This came up in my dealings with both groups, and I have to admit I was pretty amazed by the words coming out of the mouths (or the keyboards) of IBM employees.

Shut Up and Listen, but First Just Shut Up

The first issue came with the ICT group. Crazy people like me who eat, sleep, and breathe the iSeries (do you think this column is written between 9 and 5 on Monday through Friday?) were electronically out and about, and as we worked, we puttered around with ICT. After a while, a couple of interesting exchanges took place:

First, I did a little commenting:

It took a little while to get ICT loaded on my machine, but my machine is a heavily burdened and creaking old machine that I use specifically to test new comms software and other downloaded goodies. But even so, once attached, I was still a bit underwhelmed. I couldn't figure out why--the interface was quite nice, and thought had obviously gone into the concepts, but
I still didn't get more than a sense of "Huh?"

I figured out why. There's no feeling that anybody is home, you know what I mean? A couple of simple things are missing:

1. A count of people currently logged in to the various communities
2. A "foyer"...an always-open FreeJam for people to drop in and out of, just to see who's there
3. A list of open FreeJams and user counts

Little stuff like that might make this worthwhile. Until then, it's sort of a hit or miss proposition.

I thought that was a nice, reasoned comment. Acknowledge the hard work and then point out a few issues. Instead, I got some pretty unusual responses. And, it being the kind of day it was, I responded back. I'm going to recount a few of the exchanges here.

IBM: When did you try the software? You posted on a Sunday, so if you got that no one's home software [sic], it was the weekend. Even iSeries Nation "citizens" must take some time away from their computers.

Me: How condescending of you! As if I didn't know what day it is or I didn't recognize that traffic would be lighter. As it so happens, those of us who would really exercise this thing--the ones who actually eat, sleep, and breathe the iSeries community and so are in a position to make the best use of it (not to mention to be the best promoters)--do happen to be on occasionally on the weekends, as the traffic on the mailing lists will attest to. It's lighter, but not nonexistent.

The issue is not that the traffic is light, but that I had no idea who was out there. Understand this: The difference between a LAN or even a WAN application and an Internet application has a lot to do with a sense of community. Knowing who is on is a huge part of that sense.

IBM: ...its pub sub messaging. The whole point is that the system doesn't have to know who's listening. We've been tossing around the idea of providing a count of messages sent per previous time unit.

Me: I am going to give you approximately one round of "it can't be done," and then I'm just going to forget the whole thing. When you open up software to the outside community, it's no longer about what you think is right; it's about what we think is right. It's about our feeling comfortable with it and believing that the developers are listening to us. As soon as we get the idea that you developers think you know better than we do, then you've lost your audience.

As to the technical feasibility, it's doable. When people log into ICT, they send a message saying which communities they're subscribed to. When they log out, they send a similar message. You can keep either a list or a count of users, although a list would allow you to occasionally purge the list with a timeout. "Pub sub" keeps a list with each subscription. Perhaps it's not stored in a way that allows you to read it, but that's a design issue, not an architectural one.

IBM: Not possible. Also you seem to be forgetting the other applications. ICT isn't only about group chat.

Me: It's entirely possible. What you're actually saying is, "We don't feel it's necessary." See my previous point about user acceptance. Rather than tell us what you cannot do, why not actually work on doing it? This "not possible" answer is pretty condescending. Give me the specs, your objections, and a day with the developers, and I'll get you a decent design that won't overload your servers. IRC can do it for tens of thousands of users per server. Surely, you can keep up with them. (Author's note: Internet Relay Chat, or IRC, is an informal network of hundreds of thousands of users that has been doing online chat, file sharing, and Internet messaging since the late 1980s, predating even the World Wide Web.)

Now, some of you may believe that I'm a little abrasive. And I'll admit that I may have occasionally rubbed someone the wrong way, but believe me, I wasn't the only one getting the "we know better" treatment:

A User: The lack of an intuitive interface and Help text is also a huge problem.

IBM: As far as the interface goes, many people seem to like it. Once some better documentation is available, we hope the learning curve will be better.

Uh, OK. Your users don't understand the interface, and there's no help text. And your interpretation of that information is that the users are dumb and they need more help text to reduce the "learning curve." This is a rather unconventional approach to customer relations.

And what's this got to do with SWT? Well, let's take a look at some snippets of a conversation held on the SWT mailing list.

Me: In fact, that's my feeling on SWT in general. It's just not quite soup yet. It's like you're adding things at a great clip, with the intent to go back and clean things up. As an example, the lack of setters and getters in GridData as opposed to the consistent use of setters and getters in the widget classes is a little confusing. One of the great things about Swing is that the methods are remarkably consistent throughout the packages. There seems to be a little less of that structure in the SWT classes, especially some of the more advanced stuff (like the layouts).

An IBMer: When a setter/getter is provided, it implies that calling that method will cause something to take effect immediately. The use of public fields in GridData and GridLayout is deliberate.... This is a general design philosophy in SWT, not an oversight.

Me: This philosophy goes against years of OO programming wisdom and the entire concept of an Exception. A setter sets an attribute, but it allows the creator of the class to check for constraints. By making attributes public, you allow users to set invalid values and thereby get unpredicted results. Public attributes have been shunned for years for good reason. There is simply no valid reason to make attributes public.

Another IBMer: Joe, instead of arriving late at the party full of criticisms and design decisions, expecting everything to work exactly as you would have designed it, then complaining when it doesn't, why don't you try and educate yourself first?

Me: As to being full of criticisms, that's what we do in the real world. I invite criticism of my code. It's a chance to better myself. But it's obvious that here my comments are being perceived as attacks. This seems to be becoming a standard at IBM--if someone criticizes what you do, you get defensive. Rather than engage in a discussion of the merits, you instead insist that you are right and the reader is wrong. It's an interesting trend and bodes very poorly for the future of the software. If you can't get past the (understandable) pride of authorship, you are going to have problems.
 
Anyway, all that aside, let me say this:
 
1. Many of the concepts in SWT are far better thought out than those in Swing. The FormLayout in particular is an incredibly intelligent piece of work.

2. The look and feel of SWT applications are much better than those of base Swing. And while I haven't performed stringent performance tests, in general, the performance seems much crisper.

3. The amount of work in making this happen has obviously been prodigious. You should definitely be proud of yourselves as a group for having created this wonderful technology.
 
At the same time, it ain't the universal panacea. It needs work, and I hope you'll allow those of us who have been in the trenches for a while (I published a book on using Java in 2000) to help you design the next generation of the software. Convenience methods and intuitive (that is, commonly accepted) practices will help in the acceptance of your efforts.
 
I apologize if I've somehow belittled any of the members of the team. I've been developing software for a long time now, and perhaps I've forgotten what it's like to bring a new technology baby into the world. Again, you should be proud.
 
IBM: Joe, not only did I point you to a document that describes how SWT layout works and why, I fixed the code you posted. What more do you want? I suggest you go use another window toolkit that is better designed to meet your needs.

Wow! Again, an unusual viewpoint on what customer relations are all about! Notice a common thread here? "I am a Developer. How dare you question my Code? What you want matters little compared to the Design of my Architecture. If you do not like it, go somewhere else!"

That's got to be a first. An IBM employee telling me that the IBM product isn't geared for me, and I should just go find something else.

Now, you may be saying that this isn't an IBM salesperson--it's a developer. And that this is open-source software, and the rules are a little different. And I agree 100%. The rules are different--in the brave new world, your developers had better be salespeople as well, and they had better understand that no matter how good their code is, it still needs to be sold to us, the end users.

If I were a savvy business person looking to get a package from the open community, I'd look at the packages available, get on these mailing lists, and talk to the developers.

One developer says, "I want to work with you and make sure that our product fulfills your business requirements."

Another developer says, "Your criticisms are beneath me, and you ought to find another package."

Which package do you think I'd be more likely to choose?

Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. He has been working in the field since the late 1970s and has made a career of extending the IBM midrange, starting back in the days of the IBM System/3. Joe has used WebSphere extensively, especially as the base for PSC/400, the only product that can move your legacy systems to the Web using simple green-screen commands. Joe is also the author of E-Deployment: The Fastest Path to the Web. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..