You read correctly. IBM is open sourcing RUP.

My take on this? I think this is the process world's equivalent for The Daily WTF.

The only reason why open sourcing RUP would make a splash in someone's world would--in my opinion--be because that someone can now get part of the supporting software free of charge. Yeah. Too bad that the software is just a loaded gun with which you can easily shoot yourself in the foot...

Take this quote from one of the news articles Pete links to: "They will also donate 300,000 lines of code, which will serve as the foundation for a proposed tool to capture best practices in software development." Now I might be a bit daft but how on earth will 300,000 lines of software capture "best practices in software development"? No, let me rephrase that. Why on earth would we need 300,000 lines of software to capture best practices in software development? Oh, and why on earth would I listen to what "CapGemini, BearingPoint, Covansys, Number Six Software, Armstrong Process Group, and Unisys" say about best practices in software development? That's like asking a Gartner analyst to write the software for your prosthetic heart.

Yes, I'm ranting and I digress.

Seriously speaking, I see this as just another publicity stunt by IBM. They realize that RUP is not going to be the kind of cash cow it used to be for much longer. The Fortune 500 is experimenting with agile methods after the consultancies gave RUP a bad rap by tailoring monstrous processes for their clients in exchange for hefty sums of cash plus a front row season ticket in the IT project spending spree that followed.

I feel sorry for Philippe Kruchten, the 90's equivalent for Dr. Royce. A smart guy, Kruchten created a decent framework for tailoring a software process to specific situations. Then the consultants came and got it all wrong.

Sigh.

I was again away from the HQ for most of the week and today when I came back from the Merito Forum seminar, Pekka proudly showed what they had figured out with Joni while I was gone. In short, my first impressions are that this seems like a reasonably clean way of sharing fixtures between JUnit tests.

Ruby on Rails has a similar capability built right into the framework itself. Ok, ok, the Rails stuff is much more powerful than the above static import trick but obviously it would be possible to implement some sort of a YAML-fixtures-in-classpath utility on top of JUnit and Hibernate, for example.

I gave a short 30-minute demonstration of test-driven development earlier today in a tiny meeting room with almost no oxygen to a mixed audience of developers with backgrounds in various programming languages from C to C++ to some of those old proprietary state-machine based languages ending with "DL". Since my personal commercial experience in C and C++ (which seemed to have the biggest following in the room) is limited to some 3 weeks of fixing a couple of bugs in a home-grown PDF generator (populated with variables named "p", "p2", "pp", "k", and "j") while "the C guys" were on summer vacation and "the Java guy" was the only one with even the slightest chance of getting it fixed, I used my trusted companion Eclipse to show a bit of TDD live on the projector. In any case, it wasn't a problem since the process of test-driven development itself is language-agnostic (and assuming that you don't get stuck in trying to understand all the nuances of the code being shown on screen). It's the green bar and red bar that matter, and the notion of test code and production code.

Interestingly (or perhaps not so interestingly) one of the C++ guys said, instead of commenting on the TDD process itself, "Oh man, I want to do Java!", as he had watched me "CTRL-1", "CTRL-SPACE", "ALT-SHIFT-M", and "ALT-SHIFT-I" away with Eclipse.

And I agree. The tool support for TDD (or even unit testing in general) is apparently still pretty much non-existent in the C/C++ world. Yes, there are frameworks like CppUnit, CppUnitLite, CxxTest, CUnit, and so forth, but all of the frameworks this guy's team had tried had choked on some particulars of their system (don't know the details and quite possibly wouldn't understand them even if someone would try to explain since I'm really lost with my pointers). Pekka, who was also there to demo a functional testing framework mentioned a unit testing framework for C code named Check that might work. Or not. We'll see. Or they'll see, I should say, since I'm not in any way involved with that C++ project.

The same goes for refactoring--there's hardly any tools for C/C++ developers to aid them in that task, fundamental to keeping your codebase clean and tight.

This sort of encounters always remind me of how Giovanni has done refactoring on C++ code using shell scripts and regular expressions... (Much respect, brother!)