Object Technology: What's the Coolest New Language?

Smalltalk programmers have been depressed since Java started dominating the landscape, but a few of them have found hope again in a gem of a language where everything is an object, and syntax is clean, and programmers can have fun again! Ruby is highly recommended.

Efficient, Invisible Fun
The buzz on Ruby

"The most important concepts in Ruby can be written in the letters FUN and JOY. Programming is supposed to be fun, but for various reasons, we often forget that. Ruby helps you to remember programming joy again."

—Yukihiro Matsumoto, Ruby creator
Thomas, David and Hunt, Andrew. Programming Ruby: A Pragmatic Programmer's Guide. Addison-Wesley, 2000.

SCRUM Resource: Lessons Learned in Managing Object-Oriented Development

SCRUM project management is becoming increasingly important as scalability of SCRUM across multiple projects in large organizations is attempted. On 18 December, I posted a note on how to provide charts and graphs for management of a SCRUM project in less than 10 minutes per day.

For those implementing SCRUM, it is useful to understand the historical experience that has led to development and enhancement of the SCRUM process in recent years. A better informed SCRUM Master will run a better SCRUM.

Today, I was filing away one of the early papers that was useful in thinking about managing object-oriented development projects. SCRUM works for any type of project, but it is particularly adapted to the iterative cycle of object technology projects. The Pittman paper is as relevant today as when it was written in 1993. For those of you in large companies, it even indicates how to estimate projects using Barry Boehm's COCOMO methodology. While this is not necessary for most SCRUM projects, it can be useful in satisfying even the most demanding beaurocracy. It also will force you to think hard about the key forces that drive project success. Check out:

Pittman, Matthew. Lessons Learned in Managing Object-Oriented Development. IEEE Software 10:1:43-53, Jan/Feb 1993.

Boehm, Barry et al. Software Cost Estimation with COCOMO II. Prentice Hall, 2000.

Seven Steps to Pain and Suffering with the Rational Unified Process

I'v'e gotten a lot of email about the RUP patterns of failure paper, including email from the authors. The lead author, Craig Larman, has generously offered to provide copies of his paper to anyone that communicates with him through his website, www.craiglarman.com.


Larman, Craig el al. How to Fail with the Rational Unified Process: Seven Steps to Pain and Suffering. Valtech Technologies and Rational Software, 2001.

"In order to ensure absolute misunderstanding and failure in RUP adoption, we provide the following checklist or score sheet. Of course, the more points scored, the more successful the RUP failure.

You know you didn’t understand the RUP when …
o You think that inception = requirements; elaboration = design; and construction = implementation.
o You think that the purpose of elaboration is to fully and carefully define models, which are translated into code during construction.
o You think that only prototypes are created in elaboration. In reality, the production-quality core of the risky architectural elements should be programmed in elaboration.
o You try to define most of the requirements before starting design or implementation.
o You try to define most of the design before starting implementation.
o A “long time” is spent doing requirements or design work before programming starts.
o An organization considers that a suitable iteration length is measured in months, rather than weeks.
o You think that the pre-programming phase of UML diagramming and design activities is a time to fully and accurately define designs and models in great detail, and of programming as a simple mechanical translation of these into code.
o You try to plan a project in detail from start to finish, allocating the work to each iteration; you try to speculatively predict all the iterations, and what will happen in each one.
o An organization wants believable plans and estimates for projects before they have entered the elaboration phase.
o An organization thinks that adopting the RUP means to do many of the possible activities and create many documents, and thinks of or experiences the RUP as a formal process with many steps to be followed.

We are confident that by ... applying the checklist of misunderstandings, your adoption of the RUP and iterative development will be a spectacular mess."

SCRUM: Dealing with Bugs in a Sprint

Recently a question was posted on the object-technology list asking how to handle bugs during a SCRUM sprint. We have refined the art of SCRUM project management at PatientKeeper during the past couple of years to handle multiple simultaneous sprints with thousands of simultaneous tasks, integrating bug tracking with development project tracking. The requirement for the project management system was less than 60 seconds per day per developer to update, and less than 10 minutes per day for the project manager to do complete reporting with charts and graphs.

In order to meet this requirement, the developers could not use any other software program than the bug tracking system they already used. We added only a few data items to include development tasks in with bugs - class (development task or bug), initial estimate, time invested, and percent complete. Our team was already using an the open source bug tracking system GNATS. We enhanced GNATS with these data items and the ability to dump data into an Excel spreadsheet automatically, every day, for the project manager.

The Burndown Chart above was published in: Sutherland, Jeff. Agile Can Scale: Inventing and Reinventing SCRUM in Five Companies. Cutter IT Journal 14:12:5-11, Dec 2001. If you would like a copy, send me email.

The chart represents a rather long Sprint required to deliver Release 6 of the PatientKeeper mobile product for clinical results. Planning for this project started in April (while another release was in progress) and development items were entered into GNATS which included initial estimates. Initial estimates are frozen and cannot be changed after entry. This allows us to assess estimation accuracy at a later date. You can see the backlog building as new project pieces are entered. The Sprint was kicked off in June and there was a rapid increase in backlog as product marketing added new tasks and developers found out their initial estimates were too short or tasks were missing. In the initial part of a Sprint, the challenge is to get the backlog complete and start flying the backlog curve down into the delivery date. In this case delivery had a hard stop at 20 August.

As bugs are found they go into the same system. It is possible to enter estimates for fixing bugs, but we usually track them by count. The data dumped to the project manager allows the data to be look at in multiple ways. It also shows bug inflow and outflow by day so you can see how many bugs are being found and fixed as you move forward.This metric is one of the most critical information for assessing stability of the code, as well as the success of the project. In the development Sprint which ended on 20 August in this chart, the project manager is primarily focused on cumulative days remaining for unfinished tasks. On August 20, we moved into a QA sprint. The project manager then shifted to focus totally on bug counts remaining day by day, including inflow and outflow.

Testing is going on during the development cycle and tasks should not be completed until high priority bugs are eliminated. If bugs are found after the task is logged complete, it can be reopened, or the bug can be fixed by the developer owner in the midst of working on other tasks. In any case, this effort is reflected in a rising or falling backlog curve. At the end of every day, each developer reviews tasks and bugs being worked on in the same GNATS user interface, and updates the database in less than 60 seconds.

This is the best project management system I have ever seen or experienced. Time required for update and reporting project management statistics has been reduced by at least two orders of magnitude over other approaches I've seen. In addition, the Backlog Curve reflects thousands of individual estimates that are updated daily. This micro-costing of the project effort yields more accurate estimates of project completion than other approaches. Highly recommended!

Boston Digerati: Sites to check out

Sites to Watch for News of What's Next
Boston Globe by Scott Kirsner, 12/16/2002

Dan Bricklin
Dan wrote Visicalc which was the application that really started the PC revolution. It was later eclipsed by Lotus which was then overtaken by Excel. As a technologist with deep historical perspective, Dan's log is worth reading. He wrote the first piece I have seen that gives a good assessment of the potential impact of the new tablet PCs.

John Robb

"Robb has been a technology analyst at Forrester Research and Gomez Advisors, and he brings the incisive approach he learned at those two local firms to his weblog. Robb is one of the more prolific bloggers on this list, rarely skipping a day. Among his interests are alternative energy technologies and the radio frequency identification tags that could eventually be used to electronically track and inventory all sorts of physical objects, like packages of Gillette razor blades." Scott Kirsner

David Weinberger

"Weinberger, an author and consultant, attends more conferences and seminars than anyone I know, except perhaps a few audio-visual technicians. Last week, he was taking copious notes at the Supernova Conference in Palo Alto, Calif., where the central theme was the accelerating decentralization of everything." Scott Kirsner

Ray Kurzweil

"Though it's not technically a weblog, inventor and entrepreneur Ray Kurzweil maintains a Web site that's updated regularly, and jammed with conference listings and pointers to articles. There are also postings by people other than Kurzweil, like Mitch Kapor, the founder of Lotus Development Corp. and now a champion of open source software, and MIT artificial intelligence guru Marvin Minsky. (Kapor and Kurzweil have a bet going as to whether a computer will be able to pass the Turing Test - essentially, whether it can impersonate a human - by 2029. Kurzweil's money is on yes.)" Scott Kirsner

Jeremy Allaire

"With his brother J.J., Allaire started one of the earliest developers of Web publishing tools, Allaire Corp., and took it public. In 2001, he sold the company to Macromedia, where he now serves as chief technology officer in the West Coast firm's Newton office." Scott Kersner

Ray Ozzie

"Ozzie was the originator of Lotus Notes, and is currently CEO of Groove Networks, a Beverly company developing software for workplace collaboration. His weblog features some free-form brainstorming about problems as yet unsolved by software, progress reports on Web services, and musings on how to address decentralized, networked terrorist organizations like al Qaeda." Scott Kersner

Bob Frankston

"Frankston developed the first spreadsheet in collaboration with Bricklin, and later went on to work for Lotus and Microsoft. He's a crank in the best sense of the word - fiercely opinionated, wicked smart, and interested in sometimes arcane topics, like why automakers intentionally make it difficult to jack into your car's computer system." Scott Kersner

Project Management: Counting bug inflow and outflow

Cohn, Mike. (2002) "A Measured Reponse: Useful metrics to give managers the numbers to back up project hunches." STQE 4(5):20-25, Sep-Oct.

A few years ago, I was leading a large development group and the leaders of the Quality Assurance team visited me. They said they were ready to provide me any metrics I wanted. AlI I wanted was bugs found vs. bugs fixed day by day for each product along with cumulative bugs outstanding by day. Looking crestfallen, they asked if that was all.

That is all I wanted, a simple metric, that turned out to take a lot of work for them to provide it for dozens of products under development. It tells you how much QA work is getting done, how buggy the product is, whether the bugs are overwhelming the development team as you approach ship date, and so forth. You can largely predict the success of the rollout of a new product by knowing this single metric.

There does not seem to be a lot written about this simple metric. I was happy to see Mike Cohn make it the centerpiece of his article. Recommended.

Microsoft vs. IBM: In Software, Still Testy After All These Years

IBM's acquisition of Rational got a lot of press over the weekend and Steve Lohr's article in the New York times this morning has a few pithy one liners from Bill Gates and Ambuj Goyal, Chief of Strategy for IBM's software group.

"Feisty and combative, Mr. Gates says he finds I.B.M.'s software unimpressive — a patchwork of programming projects, not as coherent or as integrated as Microsoft's competing offerings. "WebSphere is a marketing term for I.B.M.'s platform," Mr. Gates said...

"But what most irks Mr. Gates is the suggestion that using Linux is ultimately cheaper than Windows. Windows, he says, is a richer platform with more services and tools for writing programs quickly and efficiently... "You take Linux and run WebSphere on top of it — that's called expensive," Mr. Gates said...

"Even with its networked .Net technology, the Microsoft lock-in mentality, honed with Windows, remains intact, I.B.M. executives contend. "Once an application is written to the Microsoft platform, it can never come out," said Ambuj Goyal, chief of strategy for I.B.M.'s software group. "It's like a lobster trap."

"... Mr. Gates laughed when asked about Microsoft's sometimes friendly, often antagonistic relationship with I.B.M. — a corporate relationship that has run more than 20 years. "When I was born, there was I.B.M.," he said. "And when I die, there'll be I.B.M."

Baseline: Fast, Free, and What's Winning in IT Shops

Baseline is a trade journal worth reading and free to object technology professionals. I like the snappy headlines like "Mission Imparsable? Arlines have sunk $51 million into technology for Orbitz. The travel service still can't keep its data straight."

Better yet, it tells what leading companies are actually doing in software development. In the October 2002 issue, trucking companies are surviving by bar coding and tracking every package. Swipe the package, swip the dock, swip the shipping clerk, add the time, and you know where everything is at all times. Too bad our hospitals can't do this. There are over 100,000 people killed every year in hospitals from medication error. The Leapfrog Group reports that 83% of the errors are preventable if physicians use technology like the truckers use.

And it is really interesting to know that the CIO of the Subway global sandwich franchise is dumping his Alpha VMS systems along with the INGRES database he has been using for 16 years. He has a bunch of VB and C programmers, all Windows desktops, and found it cheaper to go with a .NET solution. Even more interesting is that he thinks it will take at least three months for his developers to do anything useful in .NET because "they were used to programming procedurally, using Visual Basic and C. Now they have to think in terms of objects, or reusable chunks of code."

So object technology is winning in the trenches, but is .NET winning against Java? Click on the link to Java vs. .NET: How Companies Make the Call and you will get a reasonable article on tradeoffs. If you are already a Microsoft shop, .NET is the obvious choice. If you are a Unix shop, or need to be cross platform, then Java is the obvious choice. Baseline is a little Microsoft centric and probably reflects mainstream IT shops where VB tends to be the programming language of choice, so adjust for that.

Of course, if you really want to jump into the fray on Java vs. .NET, take a look at The Petstore Revisited: J2EE vs .NET Application Server Performance Benchmark and surf over to the rematch discussion on TheServerSide. You don't often hear Java programmers crying "ouch!"