SCRUM: How to Fail with the Rational Unified Process: Seven Steps to Pain and Suffering

I received a request not to post this article previously, even though it was posted elsewhere. Craig Larman agreed to send anyone a copy. Now it has a home on the Agile Alliance site for easy access. It's a good read and everyone should check it out.

How to Fail with the Rational Unified Process: Seven Steps to Pain and Suffering
Craig Larman, Chief Scientist, Valtech USA, craig@craiglarman.com
Philippe Kruchten, Rational Fellow, Rational Software Canada, pbk@rational.com
Kurt Bittner, General Manager, Process and Project Management Business Unit, Rational Software, kbittner@rational.com

Computer Languages: One Giant Step Backward

There are a series of letters in the current issue of Communications of the ACM on an article written a couple of months ago on the value of domain oriented computer languages. COBOL and FORTRAN have yet to be replaced because of their dominance in specific domains. Large scale efforts like PL1 an Ada have been dismal failures. Today's few general purpose languages are not well suited to describing financial and mathematical analysis domains. Some veteran programmers are moving toward scripting languages like Python that allow easy implementation of solutions that you would never bother to program in C++, or Ruby, an elegant implementation of objects that would make a Smalltalk programmer smile. Get in on the language debate by checking out:

Communications of the ACM
Volume 46, Number 5 (May 2003), Pages 21-23
Practical programmer: One giant step backward
Robert L. Glass

Old saying: "The more things change, the more they remain the same" ...or do they?

It is common for software developers to talk about the rapid change of pace in our field. We say things like "It's hard to keep up with all the things that are happening," and make apologies for not being up to date on the latest whatever. I've been guilty of that myself, on occasion.

But do you know what? I don't really believe it. Almost not a word of it. Except for various vendor products, such as tools and processes, the things I learned in software kindergarten, way back in the 1950s, are for the most part still valid today.

Computer hardware developers, I would assert, have made great strides in moving their field forward over the years. Smaller/faster/cheaper is almost a mantra of their fast-paced field. We software folk, by contrast, tend to build software in the same old ways. Reuse? Libraries were common in the 1950s. Coupling/cohesion and information hiding? We knew about those back then, too, although we didn't call them that. Programming languages and operating systems? The field didn't begin with them, but by the late 1950s (way back in those dark ages!) they were very common.

Bibliography Update: Medical Informatics

The bibliography link on the menu to the left is updated from time to time. I recently coauthored a paper on medical informatics with Mike Minear, CIO of the University of Maryland Medical System. This was part of an interesting DOD/TATRC project called the Operating Room of the Future. Your next surgeon may be a robot.

Medical informatics-a catalyst for operating room transformation.
Minear MN, Sutherland J.
Seminars in Laparoscopic Surgery 2003 Jun;10(2):71-8.

For many years, computers have supported complex clinical ancillary functions such as the laboratory, radiology, endoscopy, and others. Digital computers have been successfully incorporated into specialized clinical instruments to offer advanced digital devices such as fetal monitors, heart monitors, and imaging equipment. But these devices are often not fully integrated with clinical management and operational systems. Beyond ancillary department applications, the result of almost 30 years of trying to automate the clinical processes in healthcare is large investments in both computer systems and paper medical records that have resulted in paper-based, computer-assisted processes of care. This expensive combination of partial clinical automation and archaic paper-based support processes is a major obstacle to improvements in care delivery and management. The need to use software, informatics, and standards to help manage the operating room and perioperative processes of care is significant. The potential to reduce adverse events, cost of care, and to enhance the quality of care are real and worth attaining. This paper focuses on what medical informatics improvements are needed to support improvements in surgical care and to assist in the management of the highly complex operating room and perioperative care process, and proposes research priorities in these areas.