Brian Smith made some good points on my last post about software component versioning. They're too detailed to reply to in a comment so I'm posting a reply as a full entry.

You'll probably need to read that last post for this one to make sense. Also, I kind of have a strategy now. More on than at the end of this post.

I would just change the version number to 2.0, and then tell your customers that they can have a free upgrade even though this isn't the normal policy.

There's not enough new stuff to go to 2.0. It's not really fair to customers either. I think it has to be 1.2. I'd like 2.0 to be a bigger bang.

Unless you are taking away functionality I have a hard time understanding why you cannot maintain backward-compatibility. Compatability is something that everybody expects, and doubly so if they are paying for the product. It seems like the problem could be solved by adding a new interface instead of replacing an existing one.

When adding methods, this is the case. In fact I will be adding methods and maintaining the old ones. But if you want to change method access permissions it's basically impossible. I want to move a public method to protected.

Also, adding a new interface is not an option as I need to keep the name of the interface consistent across product lines. Bit of a catch-22 really. It's a bit of a pain when you have to manage more than one product. I'm starting to have some sympathy for Sun and the mess that is java.*.

The nice thing about backward-compatibility is that there is helps encourage people to upgrade to the latest version. If people refuse to upgrade then you end up supporting old versions longer. If a customer finds a bug in version 1.1 then they will ask you for a 1.1.1 to fix it, instead of upgrading to 2.x where it was already fixed.

Ah. Yes. But I do this in any case. All major versions will be supported for as long as possible. This is important. Part of the reason developers hate external components is because they can't be trusted and a lot of vendors just don't care if there are bugs. Well I care, and I won't let bugs stand if I can help it.

I don't really like the idea that the first component of the version number only changes when there is an incompatible change. If you maintain compatibility for five years then the version number would be something like 1.9. But, 1.9 probably would have much, much more functionality than 1.0. Yet, the numbers 1.9 and 1.0 don't seem that much different from each other (it is easy to misread it as 1 & 23/100). The result is that this scheme is counterproductive to marketing the product: the main version number increases when something bad happens.

The worst case would be when you publish an interface in, say, version 1.6.1 that for some reason has to change immediately (e.g. the way the interface was structured facilitates some kind of security problem). To fix this problem you want to release a fixed version of the API. But, now you have to call this version 2.x even though it might be a very, very small change. Maybe the jump from 1.0.1 to 1.6.1 was a huge improvement in functionality. Yet, the increase from 1.6.1 to 2.0.0 was a single bugfix, perhaps just a few characters changed in the source code. It is counter-intuitive.

This is a very strict interpretation. I would say that one can bump to 2.0 at anytime, for marketing reasons say. It would only be forced by a compatibility issue.

In any case, I think I am going to drop the minor version restriction and say that minor numbers can accept compatibility changes. This means that you can only be 100% sure of compatibility on the same major.minor revision. But that's pretty much OK.

It works okay for open source products because marketing for them is totally different (often ignored).

Very true. And there is something to learn from Open Source. Version numbers are an important way to give a quick overview of the state of the project. I like that and it's very useful, even necessary, for software components. It's much less important for applications, where the version number is just a marketing gimmick. But for my stuff the version number is, in a way, part of the customer service. It's very important that it has a crystal clear meaning.

So this all seems like a very difficult problem to solve. However I was forgetting one thing about Java: Just-In-Time compilation!

How does that help? Well, it means that reflection is not as bad as you think it is. The "common knowledge" is that reflection is slow. Well sure, the lookup is slow, but once you have the method reference the JIT compiler will optimize the calls for you. In the case of data processing where you perform the same operation many times, this effect comes into play very quickly.

So reflection is OK! I can use it! I'm going to look at trying to rewrite the support classes to handle this situation. They will introspect themselves to see if the old methods are declared. They can thus recognize the old interface and work with it. Old code should just keep working.

Yes this will make my support classes messy and more complex. Tough for me. That's the price to be paid. If you want to maintain compatibility for paying customers, as Brian noted above, you must do this. Anything else is just lazy.

Of course, this may not work completely. We'll see. But even if I can reduce the changes required, that's a good thing.

Thank You Blogosphere, and Thank You Brian!

My versioning system is broken. It's painful and I'm not entirely sure what to do about it. Time for a blog entry so!

Previously I wrote about my vision for the Ricebridge Versioning System. All Ricebridge components have three version numbers. For example, 1.2.3 means that you have major version 1, minor version 2, and build number 3.

Major versions allow for incompatible changes. Minor versions add new functionality but keep compatibility. Build numbers track bug fixes and minor changes. I think it works very nicely. It's pretty clear and easy to follow. And you know where you stand and what you can upgrade to. You know that a major version change will probably break your code and you'll have some extra work to do. But you also know that you can upgrade to a bug fix release or take advantage of a new method in a minor release by just dropping the jar in and continuing on your way.

I'm very attached to the three number versioning system. And so are my customers who've got very used to it. Changing versioning system is in itself a major version change really (given that you are breaking semantic compatibility), and I don't really feel like it at the moment!

So what's broken? Well I have new version of CSV Manager coming out soon. This will add a few new things, including Java Beans support. Nothing that will affect the existing code, so no problems there.

However, based on the experience gained building XML Manager, and my future plans for the product set, it looks like some of the interfaces in CSV Manager will have to change.

I want to create a coherent set of components that all work the same way. That's very important. There has to be interop, both at the code level and at the user level. That means that the APIs should be the same, Once you learn the API of one Ricebridge component, you can then apply it to all Ricebridge components (pretty much).

But the original CSV Manager API is not right for this. It needs to be modified. That breaks compatibility. So fine. We go to CSV Manager 2.0.

Except, not so fine. Not at all. You see, Ricebridge customers get an upgrade path. When you buy from us, you get the right to upgrade, for free, to a release that has the same major version. Right now CSV Manager is at major version 1. If I bump it up to major version 2, then all those customers will loose out. Ouch. Not very nice at all. Definitely not the right way to go. I want existing customers to get the full benefit of the new API as well.

It looks like we can’t bump the major version. So let's drop the compatibility restriction on minor versions. That could work. Except now, when you look at a version number, you can't tell right away whether it will work with your current setup. Not so good either.

How about using four version numbers? We can add an extra one for compatibility: major.release.minor.build. So we bump the release number every time there's an incompatibility change. Except this is not very user-friendly. Four version numbers is really pushing it. Three is just about as much as anyone can take. In any case, it's a change I don’t want, as noted above.

Another option is to stick with the old API until the real version 2.0. We can add the new stuff, but keep the old stuff in and deprecate it. This is the standard way of doing things and it is the approach that I use normally. It works especially well for adding and removing methods from API classes. But it doesn't work for interfaces that the user implements.

If you want to change an interface that a user has implemented, then you have to force the user to change their implementation class. There's no easy way round that (sadly we're in Javaland, so dynamic solutions are awkward). This happens because the interaction model between the interface and client code changes. The implementation class must provide the new services required by the client code. In some cases it might be possible to work around this, but mostly it's very messy and there is no way you can ask people to do this.

In the end, we are forced to choose between a new implementation interface and an old one. So if we want to wait until 2.0 for the big change, then we must stick with the old API for now. This works, but it increases the amount of people using the old API and makes the changeover much more painful for many more people. Microsoft has been badly stung by this many times: The long and sad story of the Shell Folders key. It seems better on the whole to take the hit now and impact the smallest number of people.

So where does this leave us? The next release of CSV Manager will include the new API. It will break old code. I'm really sorry to have to do this to my customers. It's very nasty. But the benefit will be the many ways in which you will be able to use Ricebridge components together to solve all sorts of tricky problems. It seems like a good tradeoff in the longterm.

Actually it's not even as bad as all that. The main CSV Manager methods will not be changing much and 90% of existing code should still work fine. The change will be occurring in a part of the code that is not even used by most customers (LineProviders). So maybe all this agonising isn't even necessary!

That still leaves the problem that version 1.1 and version 1.2 will be incompatible. We still need a way to communicate this and to allow users to control versioning in their own projects. It looks like an additional stream of version information is needed. We need to track API changes separately.

One idea is to have API revisions. This means publishing a detailed description of the API and assigned it a revision number. All CSV Manager releases with the same API revision number are going to be API compatible. That means you can copy in the new jar and things will still just work.

When incompatible changes have to be made to the API, then the revision number changes. A new API description is published, showing the changes, so that users can track what happened. So each version of CSV Manager has an API revision. You can show this in a table and it should then be easy for people to follow.

API revisions would not change very frequently. In fact, as we move further along with building Ricebridge components, things should start to settle down very solidly. I don't think that there will be many API revisions.

In this system, the minor version number then means: new functionality and possibly a new API revision. This creates extra work in that API revision changes have to be made clear to users, and handled carefully.

What really gets me about all this is that I had actually put in place a system to deal with it. After reading David Bau's posts about a theory of compatibility, I created a design for the user-implemented interfaces that could accommodate certain types of changes.

When you implement a Ricebridge interface, you are actually advised to extend a designated abstract support class. This class has the job of insulating you from future API changes by translating changes into the older version of what you expect. Except that this only works in some cases. To solve my existing problem it looks like I would have to write a lot of reflection code and that would probably have a bad effect on the performance of the system. It also means that new customers would find the support class to be a confusing mess. I have in fact used this technique already on one minor change to CSV Manager.

One problem that it does not solve however is that I made a mistake with the method signatures when I first released CSV Manager. Some *Impl methods which should be protected are actually public. Bugger!

So the way forward is still not clear. I am inclined to take the hit now and offer free support to all customers who need it to make the change.

What do you guys and gals think I should do?

In proving foresight may be vain;
The best-laid schemes o' mice an 'men
Gang aft agley,
An'lea'e us nought but grief an' pain,
For promis'd joy!

Robert Burns

tag-gen:Technorati Tags: software version system release compatibility Del.icio.us Tags: software version system release compatibility

If Jonathan can give away free servers, then I can give away free licenses! I've been inspired by Sun's T2000 promotion to try something like it myself.

Here's the deal. You blog about one of our products, after trying the trial version out, and you get a free single-developer license.

You can write whatever you like. Tear us to shreds or sing our praises. It's all good. We just want links

Well, you should make sure that your audience is OK with doing something like this. Full disclosure is a good idea. So don't do anything you're not comfortable with.

Before you start writing, here's the full details of the blog promotion.

Our products are data-munging widgets for Java: CSV Manager (for CSV files, surprisingly), and XML Manager (for XML files, again, a surprise there). The single dev licenses are worth $47 and $97 dollars respectively.

Oh, and the $15 gift cert you get for every bug found, that's still valid. So you might even end up with something nice from Think Geek.

No idea when I'll end this promotion, so don't hang around if you want one, get writing!

And no, I won't apologise for the blatantly linkbaiting title!

tag-gen:Technorati Tags: csv xml manager single developer license blog post promotion Del.icio.us Tags: csv xml manager single developer license blog post promotion

Hani was right. Maven really is a pain in the arse.

I have just managed to install the cobertura plugin. Not by following the instructions mind. On no.

The install instructions are to run the following command:

maven plugin:download
  -Dmaven.repo.remote=http://maven-plugins.sourceforge.net/repository
  -DgroupId=maven-plugins
  -DartifactId=maven-cobertura-plugin
  -Dversion=1.2

Well shucks ain't that nice and easy. And it used to work, because I used that very same command a few months ago and it just worked. Tip for the documentation writer: put this command all on one line and then it's much easier to cut-and-paste into a command window.

But now it doesn't work anymore. Wanna know why? Because it references a load of dependencies inside http://maven-plugins.sourceforge.net/repository/ that do not exist. Did someone delete them? Huh?

In order to install you have to drop the cobertura plugin jar into your repository manually, and then run maven. Then it picks up the dependencies from berlios.

Am I missing something here?

If you're going to release open source stuff, make sure your install just works. No arsing around. People lose interest pretty quickly when you do that sort of thing.

This is a bug fix release for bug report 0012: the TableModelLineListener object was dropping the first row of data when the headers setting was true. If you are using Swing TableModels please check if this bug affects you. As usual, all Ricebridge customers get a free upgrade with this fix.

Thanks to Jøgen for catching this one!

tag-gen:Technorati Tags: ricebridge java csv manager jar Del.icio.us Tags: ricebridge java csv manager jar

Ooh, a blog list! So commission junction (no capitals for you, ya messers!) are off my site. Here's why:

10. When they deactivate your account, they don't send you any email to let you know about it. The first time you find out is when you try to login. Bummer for you!

9. There is no way to contact them by email. No addresses on their site. Nix, Nada, Zippity-Doo-Da. Customer support is provided by international telephone numbers. Oh yeah! Do it to me baby!

8. The only way to get in touch using this new-fangled interwebnet thing is by using a teeny-tiny itsy-bitsy help form for lost passwords. No, I'm not linking to it, but it's not hard to find from the login page. Ah go on, go find it, it's hilarious. Just remember to write really small. Oh, and I wouldn't try to have a longish domain name - cos it won't fit! Muppets! /shakes head

7. If you're not making the numbers after six months, they cut you off. Hello? Ever heard of the long tail fellas? Hey I know it's just a little old personal blog, but do you have to be so mean? Not everyone can be Cory or the Doc, you know. Some us of just have our own wee little corner of cyberspace we call home. Sob …. bwwahhhaahha…

6. If your account is deactivated it can't be reactivated. Ah Holy God! databases … yesss … beeg ma-jeek! veree scaree … yesss …

5. After kicking you in the metaphorical nuts, they say, and I quote:

Thank you for allowing us to be of service to you. Client Services Commission Junction, A Valueclick Company

ROFL dudes.

4. All their mails are Roach-Motel mails. As in, you can receive 'em, but you can never reply… stimulus, no-response, stimulus, no-reponse, ...

3. Their online reporting sucks. This one is from memory since I can't, um, login anymore.

2. They deactivate your account, without confirming your final balance. Nasty. Any word on how I'm supposed to get my few pence out guys (if indeed there is any)?

And the number one reason not to use commission junction (still no caps for you!) ...

1. Their site is … puke-green. Oh my poor dear eyes.

Well CJ, it's been great, but it's time to move on. It's not you, it's me. I'm sure you'll find someone who loves you.

Wait. Actually…

Go gcreime maorlathaí­ m­í­thrócaireach do chuid infheistí­ochtaí­!
The curse of Cromwell on you!
Go scriosa cúnna ifrinn do chuid fo-éadaigh!
May you be afflicted with the itch and have no nails to scratch with!
etc.

Me? Bitter? Nah…

tag-gen:Technorati Tags: commission junction are muppets Del.icio.us Tags: commission junction are muppets

Feeling a little despotic? Need to impose your vision on the world?

Look no further than … a private island!

Sure Charlie did it. So can you!

I have just released the latest version of my open–source code–generator: Jostraca. I first released Jostraca in late 2000 and I have been unable to get rid of it since, despite repeated kicking!

So what does Jostraca do? It takes a template and generates a lot of repetitive code. Anytime you have loads of repeated code, you can use it. Now maybe with EJB3 that's not such a big deal anymore,
but if you still want just one definition of your data objects, templates can keep them DRY.

The other thing about Jostraca is that is uses JSP-style syntax, so you don't have to learn any new-fangled semi-language. You just use the language you know. And you can also use regex macros to completely define your own template syntax if you really want to. Jostraca is also language agnostic. Currently you write templates in Java, JavaScript, Python, Jython, Ruby, C, Rebol and Perl (of course!). And you can even define your own code generator formats so you're not stuck with the standard one (which just wants to dump out a load of files).

That said, Jostraca is warty. It's a work in progress and the project iterations are about 1 year(!) in length. In this business it can be quite rare to work with a piece of code for such a long time. Most projects come and go. You move on, others take over (and curse you), and the merry-go-round continues.

The nice thing about running an open-source project is that you get to step out of the coding rat-race once in while. Jostraca has been through many refactorings, and is a lot better for it. Of course, there's still a lot to do and there's a bit pile of user stories in the unassigned bucket. But no harm. I've got years to get it right. You don't often have that luxury as a coder.

One last thing. I'd like to welcome Morten Christensen on board. He's done some great work on the Eclipse Plugin for Jostraca, which was sorely lacking. He's doing some good stuff for code-generation in Eclipse.

By the way, you may have noticed that I love competitions. So here's another one. If you can figure out how I came up with the name "Jostraca", you can get a free XML Manager license. BUT DON'T POST THE ANSWER HERE! To qualify you have to send me the answer in a private mail. That means everyone has a fair chance. (The standard competition rules apply, blah-de-blah etc.)

Oh yeah. The Sphinx is kind of a clue…

tag gen:Technorati Tags: jostraca code generation template release open source sphinx Del.icio.us Tags: jostraca code generation template release open source sphinx

Jostraca now has an Eclipse plugin: CodeGenClipse! (Jostraca is a code-generator, in case you're interested.)

Open source is great. The plugin is all thanks to Morten Christensen. And he found a load of bugs in Jostraca while he was writing it, so they're all fixed now.

And that's not all folks. CodeGenClipse is not just Jostraca specific. It's a general plugin framework for code-generation. So look out for some more cool stuff from Morten in the future.

This post probably sounds a little over-excited. Sorry about that. It's just cool when open-source works out. It really is a great way to get things done. Of course, I still think there's a place for commercial stuff, but especially when it comes to developer tools, you can't beat a shared solution.

And for all you Jostraca fans out there, the long wait is nearly over — 0.4.1 is oh–so nearly, nearly ready… (and will be announced right here on this blog of course)

Woohoo! Munster wins the Heineken Cup Final!

I'd only have a casual interest in Rugby, but I'd have to say I really enjoyed the final. Nail-biting stuff at the end.

The almighty Seth Godin says: "In every category, in every profession, half the people are below average.".

Bzzt! Wrong! Na-ah. Half the people in any industry are below the median. As in, half the people are below the half-way point (which is what the median is).

But I still think his main point is right. Let's fix the math.

In any industry you're going to have star performers. Programmers ten times better than the rest, etc. We all know the cliche. That drags the average up and beyond the main group of code-monkeys or office-slaves or whatever-you-call-your-grunts. And it drags the average higher than the median. Ability is a skewed distribution:

So Seth's argument about marketing to the below average applies even more he realises. More than half of the people in any industry are below average.

But there is a counter-point: the average is a lot higher than you think. Most jobs look easier on the outside than on the inside. Assuming you are more clever than most people is a dangerous game.

As for me, hey, I'm with the huddled masses. Who wants to be a Distinguished-Engineer anyway!

tag-gen: Technorati Tags: seth godin average people marketing median Del.icio.us Tags: seth godin average people marketing median

I've been doing this online typing course, and it's been going pretty well. It's not the flashiest of sites, but it gets the job done. I would prefer more coaching, tips and advice.

So today I got to the end of the "basic" course. And what was waiting for me? The Advanced course, only $29! Hmmm. OK. Well fair enough it is a good course. So I am pretty sure I will sign up for the next stage.

I like this little business model. Particularly as all the computation takes place client side (the course uses JavaScript). But I do think they could have been more up-front about the need to pay for the full course.

In fact, I have some marketing advice for goodtyping.com, if they'll allow me. Guys, there are a bunch of online typing courses out there. They're probably all following the same basic business model. So use the fact that your course is actually commercial and not free to your advantage. I just picked your course at random. If you had sold it to me as a basic course for free, and an advanced course for a fee, with an emphasis on course quality, you would have had a great differentiator. I want to learn to touch-type and I don't want to waste time on crappy courses that teach me bad habits. A commercial course gives me much more confidence that I've made the right decision. Oh, and you can raise your prices. At least $50 and the advanced course is still worth it. I'll easily reward myself that much for having made it to the end of the basic course.

Why not go for it? You have a little gem here.

tag-gen: Technorati Tags: online typing course

Every business has "shrinkage". Stock levels mysteriously reduce. Inventories decline overnight. Products grow legs.

You'd think that the software business is different. "There's nothing physical to lift!" you say. Not true. If you're thinking of selling software via the web, take note: you're going to get dodgy orders. It's just a fact of life.

So how exactly does it work? Well you get an order in, same as usual. Now what I do for each order is check the IP address against the credit card address. You can use a site such as maxmind to do this. Unfortunately this is can only happen after the order is processed. And then you get one. An order where the IP address is from a very different country than the credit card address. A stolen card. In these cases, the email is also usually from a free email service, and is usually one of those numbered emails, as the account has been created just for the purposes of fraud. You do get the occasional sad individual who will use a traceable email address. It will show up on gaming and script-kiddie websites.

When you get one of these orders you're stuck. The perpetrator already has your product downloaded. And you have to put through a refund asap, otherwise you'll get hit with callback charges. And you should put through the refund as soon as you can so that you don't offend the poor eejit whose credit card number was stolen.

As a software company, it's not too bad — at least you don't loose money shipping out physical goods. On the other hand it makes you more vulnerable to this sort of thing, as the fraudster doesn't need a physical address for pick-up, just an email address.

Now there are a few things you can do to prevent or reduce this type of fraud. You can block certain countries from purchasing. This works, but it's not something I want to do. First, some of the dodgy orders may come from people who genuinely can't afford the products (hey – just ask me for a free copy guys! I'm reasonable). I grew up in a developing nation (South Africa), so I can understand that. Second, other folks from those countries want to do legitimate business, and they should have the chance to do so. I just don't like the idea of blanket bans.

Another thing you can do is have more stringent automated checks, based on IP and email address. Given the relatively low level of this problem, I'm not sure it's worth it. It's not like the bad guys would suddenly decide to play by the rules as a result. They'd probably just try to hack the trial download instead (Hint to bad guys: please hack the download instead of using fraudulent credit cards). So I'll put the time into coding features for my products instead.

Finally you might want to sign up with a fraud detection service. Never used one so don't know how well they work. Maybe I'll do this if the problem ever becomes really bad.

If you sell stuff on the web, you will get credit card fraud. It's a cost of doing business with the entire planet. And hey, doing business with the entire planet is a much bigger win than losing a few sales. So I guess my final advice would have to come from Tony: "Suck it up!"

One other thing to note, if you are developing a software product for download via the web: really strong copy protection is useless and a waste of time. It seems to be really easy for certain groups of people to get hold of stolen credit cards, so they'll just buy a copy. A nice, easy way to get around your oh-so-clever copy protection. And then you loose anyway. You could opt for "phone home" protection, but that has it's own issues, like customer privacy. (And don't even think about using a dongle! How sad.)

This interwebnet thing is no bed of roses. The rules are different and you'd better leave your outrage at home.

tag-gen: Technorati Tags: credit card fraud software web download Del.icio.us Tags: credit card fraud software web download

When you find a bug in a purchased Ricebridge product, you will get a $15 ThinkGeek Gift Certificate.

A lot of software shops talk about quality. A lot of people really want to build quality software. But nobody wants to take the hit for bugs. "Of course you'll have bugs," they say. "Bugs can't be avoided!" "Bugs are a quantum necessity!" (OK, I don't know what a quantum necessity is, but it sounds pretty final.)

So there are very few who will step up and say. "Sure, if you give me cash for my code, there should be no bugs. At all." Now there was this little-known guy, (Knuth, or something like that) who did hand out cheques when you found a bug in his stuff. I believe his code has been bug-free for years.

But let's be honest here. The human animal responds to incentives. Plain and simple. We do what gratifies us, and we avoid danger and negative outcomes. Now Ricebridge is a pretty agile shop, so I've got all the gratification I can handle, software development-wise. But it just isn't enough to get rid of the bugs. And there are a lot of people throwing all sorts of development practices at bugs, in the hope that happy, gratified, developers, will code perfect code and perfect products. Ain't gonna happen. We humans are too stoopid.

So we need a new tack. A bit of danger. Some thrills. There's nothing like a kick up the arse to get you moving. I'm deadly serious about bugs at Ricebridge, so let's up the ante. Let's go for broke. Bugs have to hurt. As coders, they have to hurt us, not just our users.

So here’s the deal. If you invest in my products, and you find a bug, I will give you a ThinkGeek Gift Certificate for $15 dollars. It's real money — you can buy cool nerd stuff with it. Specifically I chose ThinkGeek so that you could get some fun out of my mess ups.

So it's time to get serious. I'm going to make 100% bug free software. It's not just a goal, not just an intention. It's something that is going to happen, no matter how many Swiss Memory USBs it takes!

(Note: I'm a ThinkGeek affiliate, but I reckon it would take a year to earn even $15 that way, so the $15 comes right out of my pocket.)

Running a Java 1.5 SAX XML parser on the UltraSparc T1 is five times slower than running it on my Athlon 2800+.

That's about right. Five times slower. Now when I got delivery of my new T2000, I thought, "Hey, this baby's gonna rock!". Then weird stuff happened.

First, I ran the performance tests for my Java CSV Component. Twice as fast. Okaaay. Well, fair enough, it is faster. Would have expected more though.

Then, I ran the performance tests for my Java XML Component. Five times slower. Eek!

Alright, I thought, slow disks! Nope. Doing the tests in memory led to the same performance. And the disks were slow, in case you're wondering.

OK. Maybe my code is to blame. Let's do a pure and simple SAX parse, with no actions. Still five times slower! So now I was getting depressed. My lovely new T2000. Broken! Or worse: Crap!

So I went out for lunch.

And then it hit me. Duh! 32 hardware threads over 4 CPUs (and that's just the minimum config). And I was only exercising one of them! My performance test only runs in one thread. You see, the T2000 is designed for throughput. Serving lots of web requests all at the same time. That sort of thing.
[Update: I wrote the original post from memory — the are only 16 hardware threads. But I'll leave the rest of this post the way it is, so you can have a few laughs. The final conclusion still holds as you can get higher spec T2000s with more CPUs].

So I run a really brain-dead test. I opened up a whole load of consoles and started the test on all of them, all at the same time.

Pay Dirt!

Not a wince. Not a whine. Cool as a breeze. Same speed on all consoles! The T2000 just laughed at me. A few samples from mpstat, and I was a happy camper again. You see, each thread may be a bit on the slow side, but you do have 32 of 'em. So if each one is five times slower, you need five threads to do the same work. But: five into 32 total threads gives you six or so. Which means:

Six Times Faster! Baby!

So what you get with the T2000 is a big old scalability lever, and a fairly small performance lever. Same old story really. There's always a trade-off.

Now maybe I was doing some wrong. I don't know. You tell me. I've been out of the game for a while when it comes to Solaris.

Here are the performance tests I was running, in case you're interested: XML Manager, CSV Manager.

So I don't know what this means for my report on the T2000. The single thread numbers suck, but the concurrency rocks. Guess I'll need some new charts!