Slashdot Mirror
IBM Donates Parts of Rational to Open Source
slashbob22 writes "IBM has decided to contribute portions of the Rational Unified Process to the Eclipse Foundation. From the article: 'RUP is a vast collection of methods and best practices for promoting quality and efficiency throughout software development projects. IBM's donation will also provide a foundation architecture and Web-based tools for the industry to engineer, collaborate on, share and reuse software development best practices.'"
If you can't sell it....DONATE IT!!!
I've used Rational(tm) before and thought it was great at what it claimed to do. Much like UNIX(tm) and GNU/Linux(tm) applications, it did one thing and it did it well.
Now, combining Rational with Eclipse(tm) should make the latter even better!
If you "get" pointers add me as a friend (116)!
As an intern at IBM this summer, I found that some of the regulars themselves didn't know what RUP was. In particular, some claimed it was simply a process to follow, some linked it with a special program, others claimed complete ignorance, and others simply waved it off as labeling the pre-existing procedures. I still wonder what RUP is all about...
Robert Bindler
A Computer Science student's views on technology.
I've been a RUP user/proponent for several years. This may be, as the article alludes, a shot in the arm for improved processes. However, it remains to be seen just what the "subset" of RUP entails. RUP can be an unwieldy process that, if used in the (lowercase "e") extreme, make development slower and more "process-laden."
However, from what I've seen lately out of some shops that are using more "modern" approaches (and failing miserably) this could be welcome relief.
Successfully condensing fact from the vapor of nuance since 1998.
Opera is the best browser out there and has been for years, but no one was buying it so they first gave free coupons away for it here on Slashdot a couple months back. Then they enjoyed the press so figured let's just give it away for free with no ads.
Granted, Firefox is excellent but Opera has been amazing for at least half a decade and is useable on everything from PCs to cell telephones.
If you "get" pointers add me as a friend (116)!
That's why Rational Rose is such an efficient, consistent, bug-free software.
</sarcasm>
I don't know about other people's experiences, but some of the worst pieces of software I've ever used have been CASE tools (you know the type: UML, lifecycle, etc). Kinds of make you question the usefulness of those tools and processes.
Look, we are and I'll admit that. I'm not afraid to criticize myself and other developers:
- Me and other coders are often eager to jump right into projects instead of designing them thoroughly (using RUP for example)
- Other coders and I often get bored after I figure out the hard part and say the rest is trivial
It's more of a work ethic. Also, my friends in the gaming industry (Electronic Arts(tm) for example) work 60-80 hour weeks, so it's understandable that they seek out shortcuts.
Let's agree to work a little harder and/or smarter and not skimp on design! USE RATIONAL!
If you "get" pointers add me as a friend (116)!
IBM is "donating" the methods of RUP to open source projects? I thought IBM liked open source?
As far as RUP goes, it's kind of like communism. Looks good in theory, but goes all pear-shaped when real human beings get involved. Pull the UML out of RUP and leave it at that--the rest is madness, enobling "process" over productivity.
Remain calm! All is well!
Finally I can figure out why Rational's products suck so badly.
I know that the company "Rational Software" was bought by IBM a year or so ago, as my mom works for Rational. But does this software suite have to do with the Rational Software company?
Granted, Firefox is excellent but Opera has been amazing for at least half a decade and is useable on everything from PCs to cell telephones.
Opera isn't so great. I bought a copy, and it wouldn't display hotmail pages correctly. I could view messages, but I couldn't empty my junk mail folder; the javascript was somehow broken on it. I could only delete my mail about half of the time; seemingly at random.
I gave up fighting with it, and moved back to Windows and IE. Yes, hotmail sucks, but it's at least reachable when my computer breaks.
My unix account was totally unreachable when my last monitor blew out, and I was forced to rely on the terminals at the public library. Hotmail is reachable just about anywhere, and you don't need to install special software on other people's computers to use it.
OMG! Now Microsoft will be able to use it and write good products.
[[SLAP]]
Oh, never mind. Everyone knows MS would never be caught dead touching anything OSS.
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
Well, maybe, but IBM Rational Rose XP is worst usability wise
/action/(/a/,/b/)
then the old Rational Rose.
Also, if Rational Rose XP is a plug-in for Eclipse, but Rose is 30x the size of eclipse...
which one is really the plug-in?
And why do you need Eclipse?!
I think it was just a fast way for them to bloat up Eclipse,
and reuse existing Eclipse parts to recrate Rational Rose XP.
It crash less often than the old, but it eats way more memory.
For instance, you cannot create some non-implementation abstract specification scenario diagrams with ease, it force you to create "implementation classes", especially when you have to dupe the classes to remove some "not meaningful" associations, instead of having a "hide association" boolean config.
It also add some freaking slash:
instead of just action(a,b) for scenarios.
Some configuration settings are no more available.
Changing colors/font of some items is no more possible in some cases.
Coordinates on infinite planes are just weird...
If you prefered to have text below the use case that's no more possible,
which sometimes makes use cases diagrams looks odds
with some having large and other small ovals or having
to put a large ovals on everything just to make it similar,
reducing the amount of stuff you can fit on a page.
It force you to include association to be displayed,
even though it is "not meaningful" in the current displayed context.
Especially, if you try to create a higher abstraction view.
The cool class diagrams private/protected/public icons
are no more replaced with boring text symbols.
It force you to use some "templates" and completely ignores
"what you actually want to do". Also, it display all
unmeaningful icons on the left using a non intuitive
hide/show menu and then prohibits you to use them,
instead of having a simple toolbar like in the old
to draw your diagram and remove non-usable one.
Basically, give me back a bug-fixed Rational Rose (non-XP) app.
2. Thou shalt not let thy buffers overflow.
I hope those are in the Rational Unified Process (perhaps the construction phase of RUP).
Two wrongs don't make a right, but three lefts do.
Garbage In, Garbage Out
First, I have personally used the RUP successfully. The success was in spite of the process, not because of it. The excellent people I had on my team made the work a success, and not a paperwork-on-rails approach to software development.
On the upside, the RUP is geared toward control of iterative projects. On the downside, it treats every diagram you draw as though it were as valuable as the working software you really intend to produce. It also adds artificial divisions between roles in the process (the architect sends X to the analyst who elaborates it and sends it on to the developer who extrudes Y...). It tends to reduce communication among team members, and between team members and stakeholders. It's original intent seems to have been to give all the diagrams in the UML a reason for being (and by extension, Rose).
Show me a failing unit test and I'll show you a low-level design awaiting implementation. Running code trumps "managed artifacts" any day.
It took me 20 minutes to save my first CASE tool work, I couldn't figure out how to save!
The only 'practice what it preaches' tool I have used is DENIM from phys.cam.ac.uk - it is a joy to use and learn, a little complex but very expert, and improving. Also try DASHER a fun little alternative input device that I just love to use.
A wise programmer once told me, on a subject of methodologies, extreme programming, UML and other design practices and work ideals:
There is no substitute for writing good code, concentrating, thinking, reading code and testing the code thoroughly in your head, understanding it as fully as possible. And at the same time knowing that although this is far from infallible, there is no substitute for it.
I dropped my fancy pants eclipse 'plugged to the nines' IDE, I dropped my newly adopted, CVS commit report friendly unit testing, over documented code, lengthy cvs commit notices and hyper-refactoring for:
emacs editor (which sucks, but I like mouse independance). Clear thought out design (my approach, not emacs), well established pattern, talking to my co workers about WHICH problem to solve, not how best to implement THIS fix to THIS problem (an outlook that changes the structure of how you write). I write more like a novelist now, making sure all the characters behave, the story sticks, and I never have that stomach churning 'oh I have to patch this bit, or add this method here, or reuse that bit there' feeling.
This is not an endorsement for emacs, which is the typist equivilent of tap dancing on a mine field after 10 shots of flaming absinthe. It does the job, and lets say it keeps you sharp (it also punishes any mistake, and whim to use copy paste, so in that respect it gives you pause for thought).
This 'clear thought, focus, concentrate and follow simple tenants of patterns and expected code conventions scales well, and transcendes language, environment and platform. It is not a 'lightweight' methodology, short cut or streamlined approach though, not by far!
So a sway from continuous evaluation, and hand holding unit tests to better planning, and more meticulous clear headed implementation (and writing in a way to maximize the chance of compiler time errors, and minimize the chance of runtime errors... compiler error good, runtime error bad)
The only bugs I see are ones that were in my original design, that is, my original thought was bad, or I translated it bad, but in a way that is clear from my development, that self documents almost every important condition statement with calls to private methods that add a sort of meta data to the blocks of code, and make it read like a story, and quickly allows you to 'sign off' on smaller chunks of code that you can handle in your head and say 'yes this works for all conditions (that is, you know it checks all null type, ranges and possible error conditions in those short 10 lines).
#hostfile 0.0.0.0 primidi.com 0.0.0.0 www.primidi.com 0.0.0.0 radio.weblogs.com
Giving away half a product away may not seem rational, but it is shrewd. You have the engine, would you like to buy the key.
... Now, THAT would have been irrational.
As for for the decision to give half the product away, I understand IBM was thinking of giving away the square root of the product away
Look at the 80 character line lengths in the parent post and thus the premature line breaks.
You obviously copy+pasted this post from somewhere, which isn't cool to do unless you properly attribute it.
If you "get" pointers add me as a friend (116)!
yeah, unit tests kick RUPs overbloated process into the wilderness
I cannot get over the idea that OSS projects have been suffering from a lack of the RUP. We have been making do with distributed SCM, email and wiki collaboration, bugzilla, xUnit testing and plaintext artifacts. Oh, and well documented code.
Now that we have the RUP, we can stop all that and do fancy UML pictures showing how use cases are implemented instead. I am so overjoyed,.
I don't know too much about RUP (read here) but here is what I do know. With RUP comes the RUPP, a set of RUP Products that are meant to facilitate the development process that RUP is supposed to be all about.
However, some of IBM's products that are part of RUPP are shit. Rational Software Architect (the 'visual modeling' part of the RUP process) is the most bloated piece of crap I have ever used. It is unintuitive, a massive memory hog, slow, and overall just a bad piece of software. About the only thing it gets right is that it is UML 2.0 compliant and has all the different models...but I have found that there are many cheaper UML modelers that are better.
Heh in a way it is just like Eclipse (which is what RSA runs on top of) - too much crap that is inaccessible. The trend in software for a while has been adding new features that people don't know about. I believe MS had the same issue with Office in a survey they conducted, where they asked people what features they wanted to see in Office and 95% of the features were already there, but people didn't know about it. For every feature added for functionality, there should be two more added for usability!
Similarly, for a programming process/paradigm to take hold, developers need to be provided with (process-related) tools that are lightweight and approachable. A process that is too rigid, too heavy-weight, etc. will never be adopted - worse yet, some team will start using that process then slowly become lazy and soon they will be in a middleground of incomplete requirements, specifications, design docs, etc.
Who do you get to be an expert to tell you something's not obvious? The least insightful person you can find? -J Roberts
What exactly does it mean to donate a software development process? Wasn't the Eclipse Foundation already free to use RUP for the development of the Eclipse environment? And couldn't companies using RUP already use the Eclipse environment for their projects?
That's because RUP is anything you want it to be. When cornered, they call it a "process framework" rather than a process, but all that means is you are right no matter what you do. Waterfall? Extreme Programming? They are all flavors of RUP.
Donating parts of RUP to Eclipse is a way for more projects for IBM process consultants. Also it is an indicator that IBMs client, usually large enterprises, are using open platforms like Eclipse.
IBM donates parts of the most retarded, inefficient, bug ridden and downright atrocious software suite in the world to Open Source. Open Source folks don't want to touch it with a 10 foot pole.
Honestly, people. Rational Suite is the shittiest, most pointless piece of garbage I've ever used. The only useful part of it is Rational Rose, and even that you can find a good replacement for.
My company decided to go with RUP a few years ago. It took months of classes and basically just an iterative process that has very heavy on process and paperwork and is based on UML. Very unproductive in the environment I worked in. A few lines of code changes could result in 40+ hours of paperwork and reviews. So I saw in practice you start with RUP, strip out what you don't like, and you end up with simple iterative process we could have thought of ourselves rather than spending a ton of money on Rational consulting. The Rational products for doing the modeling were crap. Couldn't stand them. I like Rational's ClearQuest for bug tracking and ClearCase for source control but other than that the rest was junk.
Hey IBM why don't you donate the voice recognition software and voice standard recordings (ViaVoice's voicing library)? It would be sooo nice...
Hatredman
What did you use? Marshall, Soldano, Fender or Mesa-Boogie?
Hatredman
To quote Larry Wall, "the three great virtues of a programmer are Laziness, Impatience and Hubris".
The only valuable piece of software owned by Rational is purify. Does anyone know if IBM donated purify to open source or did they keep it to themselves?
While what I understand of RUP is that it tends to go overboard with extreme implementation of basic ideas, the root of their labor division is in the excellent practice of not allowing one coder to push his code changes all the way through to distribution without some amount of validation by another set of eyes.
I'm part of the enterprise change control staff at my company, and I can tell you that the more tightly we implement controls, the more often we discover that the problems that arise are from developers implementing untested changes without authorization. If you force them to submit change documents, and don't let the changes get into the code base until the change has been authorized (for that matter, don't let them code until the change has been authorized), then have someone else test the changed software before the code gets pushed up, you've got a three-legged stool to stand on, and you have an auditable process that maintains accountability.
I bet if you look at the submission process of any successful open source project, you'll find the same constructs, maybe just not called out so formally. The basic ideas aren't bad, just some implementations. RUP gives you a framework to design your procedures with.
The Spoon
Updated 6/28/2011
The whole Rational/IBM love story is about the great american management dream. Which is, take a sh?thead, have him/her/it read a book and learn a process and you got yourself a terrific programmer. The minute he/she/it starts putting on airs, you fire him/her/it and get another sh?thead.
The folks who founded Ratioanal made a lot of money by playing that game with IBM. I remember being sent to a class design class 12 years ago where they'd have you write up class functions, properties, forget what else on pieces of paper, shuffle the pieces a few times, and supposedly you get great class design that way. Then it was some other nonsense, then some other nonsense, now it that RUP thing. Give me a fscking break.
Purify is ok (I think because Ratioanal bought the product, not developed it), the rest of their stuff is utter crap.
Unless that running code happens to be on Mars, and is not quite running as expected. Then those managed artifacts become very useful.
...F-ing cool. I know this won't win me any mod points... just think it's great.
v.m
I have a "Zero Policy" tolerance.
*/
What's the open source community going to do with a bunch of makefiles and white papers? :^)
"Let me ask you: How would you propose talking about "Software Process" without using your so-called, "buzzwords?""
Maybe by starting with the consequences of their decisions.
That's what systems analysts are there for: analysis and design. ;)
I have yet to see RUP 'produce' anything really useful - other than wadloads of cash for 'consultants' and bunches of documents for managers to point at saying how 'profesional' everything is.
What I have seen is lots of frustrated users, testers and developers and lots of layers of rubbish code.
With any luck, this 'donation' might stimulate some folks to turn it on it's head and actually provide some useful and simplified process guidelines, perhaps "PUR".
The tools stand for the process though. If they used RUP to create the tools, then you would expect the quality of the process to be reflected in the tools. If they did not use the process to create the tools you need to ask why not.
So while I agree you don't need the tools for the process, I judge the process itself (I have never used RUP for a project) in part by the tools created with it.
Though really all this proves is the process isn't a silver bullet, something Fred Brooks predicted years before it was dreamed up.
> I'm part of the enterprise change control staff at my company, and I can tell you that the more tightly
> we implement controls, the more often we discover that the problems that arise are from developers
> implementing untested changes without authorization. If you force them to submit change documents, and
> don't let the changes get into the code base until the change has been authorized (for that matter, don't
> let them code until the change has been authorized), then have someone else test the changed software
> before the code gets pushed up, you've got a three-legged stool to stand on, and you have an auditable
> process that maintains accountability.
don't forget "The Law of Unintended Consequences" which shows that:
1. as accountability goes up attitude, morale, productivity, and efficiency go down
2. once you hit critical mass on paperwork, process, etc you destroy motivation - there's some point on the curve at which point everyone just says 'who cares' and 'why bother'
3. it's impossible to really anticipate everything upfront, which means that minor changes that in a system and organization that embraces agility & resilence can be easily handled in stride take 40x as long in an organization afraid of blame.
4. most of the work is done by the motivated and talented 10% of the staff. these people leave rather than put up with the bureacracy designed to hinder the 90% that are unproductive.
RUP is a disaster, I've seen it absolutely wreck companies.
Heh, we are the Slashdot minority. We know that to post something truly funny but maybe slightly un-PC (to the Slashdot majority), better post AC. Or to post a sincere but divergent opinion, better post AC. And read at -1 so we see each other. Upwards of 80% of what's modded down is stuff worth reading.
I don't care so much about RUP, but I would like to be able to produce a decent class diagram from source or by hand when I want one and no such tool seems to exist in all of open source... Everything out there (including Argo UML) just sucks.
Pat
...I actually agree with you.
However, I always saw RUP presented as an array of smaller, compatible processes within the iterative process. IOW you adopt an iterative cycle in your collective workflow (very easy by itself) and pick what you need out of the (admittedly large and overspecific) RUP. Or you take the whole RUP and 'knock-out' what you don't need. RUP the standard anticipates this, even though RUP the product could provide more help in this regard.
With that said, I believe that FOSS projects have suffered greatly by not formally recognizing and docucmenting use cases. Excepting Mozilla and OpenOffice, the evidence abounds. It probably flows from historically "scratching our own itch" and often not maintaining requirements in the first place.
RUP is, in fact, a process to follow. It stands for Rational Unified Process, and defines a set of Roles, Activities, and tools used to write software. It goes into extremely exacting detail, which is, in my opinion, it's biggest weakness: unless you've memorized huge chunks of RUP, you spend a lot of your time trying to remember how to follow it. Once you have, you've spent too much time.
The activities described by RUP are supported to varying degrees by the various Rational tools: Rose for modeling, ClearCase for source control, and ClearQuest for issue tracking.
is that most folks don't understand the point of process and follow the letter of the law (or worse, claim to follow it but really aren't) without understanding the hows/whys associated with using a process. Pragmatism seems to fly out of the window with either draconian enforcement of artifacts or processes that bring little or no value "because they're part of the process" on one extreme to all process being thrown out on the other extreme. The worst cases are where business buy into either create "one process to bind them and in the darkness find them" (ooop, I meant to say one process for all projects) without allowing for the process to be tailored or have individuals who bring no real value other than to create more processes to hide the fact that they really bring no value.
In my nearly 30 years of experience, I've worked across the entire spectra of process levels and what I have learned is that you inevitably have to tailor the process to the project based on things in the process that bring real value. Too often I've seen project teams of 5-10 members saddled with a process designed for a team of 50-100 members because "that's the company process".
RUP is no better or worse than any other process on its own. It can be tailored to scale up and down like any other process. Unfortunately, it has come to be associated with nothing more valuable than overhead thanks to the way it's implemented (thank you major consulting firms whose sole focus is to charge senior consultant salaries for junior consultants and then bilk, er, milk the customer for all they're worth).
But your mileage may vary......
check out umbrello!
Je fume. Tu fumes. Nous fûmes!
Having worked for Rational (and, depending on how you turn it, having worked for IBM for one day - I quit soon after the merger was announced), I say: They'd better donate Rational Purify and Quantify for Unix. Now THAT is a really great product that actually helps developers generate good code. Or Rational Test Realtime, (formerly an Attol product) - neat thing, too.
RUP is a collection of posters for all I care, that people use to say "hey look how elite our development/testing process is". Its not neccessarily a bad thing, its just hardly applicable to either small OS projects or those that already have a fine, working, controlled development/release process. The whole RUP thing still doesn't prevent companies from making sucking software and testing and QA cycles are the first to drop dead when the beancounters want to release the product for some quick $$$.
"If widely adopted, this could improve software development practices within organizations and throughout the industry. It also could improve the ability to quickly respond to business and market changes that businesses are achieving through standardization in other areas, such as Web services and Service-Oriented Architecture standards that integrate previously siloed data and applications with customers, partners and suppliers." And increase IBMs Rational Tool's sales?
Hmm .... so by using RUP, does IBM think that entire software industry's success average suddenly goes up ? Software projects doesn't fail because of the methdologies, they fail because of people. And every one busy telling that "Use XP", "Use SCRUM", "Use RUP" etc. etc. No one says "Use Right People". Once you have the right people to build the product or execute a project, they'll create their own process and they'll follow it and make sure that the project-building is a success. Software projects are diverse in nature, each one is as unique as the other. No single methodology can provide the perfect singular approach for every kind of projects. It's the people, not the process.
Vijay Kiran
I blog, therefore I am.
This is great news! Now even people without huge piles of cash can use RUP to screw up their product development process. It won't just be the big well-healed companies that can afford to build mediocre products at a snail's pace - now everyone can do it!
... write no line of code before its' time ... round and round and round we went. In both cases (pun intended) we spent a fortune on tools, months on training and then about half a year wrestling with the tools and the process, until we ended up dumping it all, and writing it off as a learning experience.
I have had experience with the RUP in several companies and the results were the same in both places. Analysis-Paralysis
The more you regulate a company, the worse its products become.
We took over a project with code versioned on Clearcase. We also had a well trained admin/developer (about 10k in training and prior CC work) and sent 3 other developers to a 2k training class. Although our support group is small we maintain a lives and property critical system. Note we are not a RUP shop - just using Clearcase for source/build/documentation control. (We use the Unix version not Windows.) With a small shop like ours it's overkill but that means our hardware demands aren't so bad. I concur our savy admin guy makes all the difference. CC is easy to use for the developers but the admin really needs a deeper understanding. I have heard both glowing reports and horror stories. The common thread is if the admin has it together and is well trained in CC. Properly administered it is a transparent system with great versioning/branching/merge that scales even in distributed shops.
If the development team is undisciplined enough to require a formal process, then RUP is one of the least harmful heavyweight processes. But make no mistake, it is heavyweight.
The truth of the matter is that you can automate much of the gating needed to keep "unauthorized" code from making it into production. The key to your statement is that developers were adding "untested" changes to the code base. Part of the demand of agile processes is that you write code to make a test pass (whether this be an acceptance test or a lower-level unit test). The net effect of this is that disciplined developers write code that is required by the nature of the system, and the nature of the tests. Even at an architectural level, you can automate verification of architectural styles. This tends to require a more significant effort, however.
With regard to open source, the issue is one of communication. Developers may be in different time zones and may rarely have the opportunity to speak to each other face to face. There is a minimum of process, but it is to coordinate general direction for the project, and even in these cases, working code, proven with tests makes the strongest argument in favor of a particular approach.
My suspicion is that you are catching the issues you are because people are sitting in a room, face to face, and talking about it. The change documents simply set the agenda for the discussion.
Try umllet at http://umlet.com/
The UML is junk. Where does an ERD fit in with the UML? What about object-relational impedence? These are basic questions, and until the UML addresses them in some explicit fashion, it will remain junk.
I'd much rather they open source CMVC but since that would compete with the Rational line I doubt we'll ever see that happen. CMVC was an IBM configuration management and defect tracking system that they marketed for a while. I understand it is still widely used internally at IBM.
Can IBM write off this donation for tax purposes? It seems that big companies would be more willing to contribute to OSS if they could count it all as donation for tax purposes. Not just assets, but employee salaries as well.
It looks nice, but is there a way to go from source code to a diagram? Or perhaps some additional tool to bridge that gap?
thanks,
Pat
If this is the same process used to design Lotus Notes, I'd avoid it like the plague. Or bird flu for that matter. No wonder they'd give it out for free then.
--ngoy
You've sat in on our change control meetings, then?
I'd honestly like to see a lot more automation in our basic development process. We're using Serena Dimensions as our code repository and change management tool, and it supposedly has command line-based APIs to use for a lot of automation, but the process is so convoluted and the system so delicate that the slightest mishap means a major recovery process for the whole database. Henceforth we have this really expensive, fully integrated tool that we use about 10% of the functionality of. We're busy implementing a major version upgrade, and maybe things will get better, but I'm not holding my breath.
My basic idea around all aspects of "what you did when" documentation, including everything from how you spend your time during the workday to who authorized code changes, is that it should be as hidden as possible from those doing actual work. That means a whole lot of low-level tool automation and integration. But, unfortunately, I'm not in any sort of position to push that agenda, so I sit idly by, watching as more layers of management and reporting requirements be implemented, forcing "individual contributors" (oh, how I hate that phrase) to drag more and more heavy anchors behind them.
Still, I value the basic ideals of good change control. If nothing else, it keeps people talking to one another, and keeps people in touch with what things are happening in other parts of the enterprise.
The Spoon
Updated 6/28/2011