Bjarne Stroustrup, inventor of C++, on what's wrong with most software ...

The Problem with Programming
By Jason Pontin, Tuesday, November 28, 2006

In the 1980s and 90s, Bjarne Stroustrup designed and implemented the C++ programming language, which popularized object-oriented programming and influenced numerous other programming languages, including Java.

C++ remains the archetypal "high level" computer language (that is, one that preserves the features of natural, human language), and it is still used by millions of programmers. Many of the systems and applications of the PC and Internet eras were written in C++. For all that, the language remains controversial, largely because it is notoriously difficult to learn and use, and also because Stroustrup's design allows developers to make serious programming mistakes in the interest of preserving their freedom.

Stroustrup, for many years a researcher at AT&T Bell Labs, is now a professor of computer science in the Department of Engineering, at Texas A&M University, near Houston.

Technology Review: Why is most software so bad?

Bjarne Stroustrup: Some software is actually pretty good by any standards. Think of the Mars Rovers, Google, and the Human Genome Project. That's quality software! Fifteen years ago, most people, and especially most experts, would have said each of those examples was impossible. Our technological civilization depends on software, so if software had been as bad as its worst reputation, most of us would have been dead by now.

On the other hand, looking at "average" pieces of code can make me cry. The structure is appalling, and the programmers clearly didn't think deeply about correctness, algorithms, data structures, or maintainability. Most people don't actually read code; they just see Internet Explorer "freeze."

I think the real problem is that "we" (that is, we software developers) are in a permanent state of emergency, grasping at straws to get our work done. We perform many minor miracles through trial and error, excessive use of brute force, and lots and lots of testing, but--so often--it's not enough.

Software developers have become adept at the difficult art of building reasonably reliable systems out of unreliable parts. The snag is that often we do not know exactly how we did it: a system just "sort of evolved" into something minimally acceptable. Personally, I prefer to know when a system will work, and why it will.

TR: How can we fix the mess we are in? ... Click here to find out!

Agile Performance Reviews

MEMO – June 1996 (updated Mar 1997 for IDX RISD, Feb 2000 for PatientKeeper, Nov 2006 for Scrum Alliance)

To: All Development Staff

From: Jeff Sutherland
VP Engineering, Individual
SVP Engineering and CTO, IDX Systems
CTO, PatientKeeper

Subject: Performance Reviews

Over the past 10 years, the attached review process was evolved during the first implementation of Scrum at Easel Corporation in 1993 and enhanced in several leading software companies. Hyper-performance teams have used this process to accelerate their effectiveness. (Hyper-performance teams deliver product in record time and computer journal editors write rave reviews and say it is the best product of its type that they have ever seen.)

This review process:

• Allows the review to be a better means of communication with an employee.
• Helps build mutual understanding on performance, personal goals and objectives, company goals and objective, training needed, and objectives for the next three months.
• Makes the rating system more objective by focusing attention on the user experience of the product being developed, along with time to market. The subjective experience of the manager is deemphasized.
• Require raters to all work closely with one another to sanity check ratings. It is not easily managable on a large, impersonal system, as currently used in the IDX peer rating system in 1997.

---

The Process Takes Three Meetings to Initialize

Meeting 1: Reviewer meets with employee and goes over this document. The employee is then asked to write his own individual review after the meeting by responding to the key questions (see below) and giving him/herself a rating. The employee can write a little or a lot. This review is designed to minimize the amount of writing.

Meeting 2: The second meeting occurs when the employee returns the review (along with soft copy). The reviewer discussed the employees perceptions to get a good understanding of them. After the meeting the reviewer carefully edits the review to incorporate the reviewers perception of performance.

Meeting 3: The third meeting occurs after the reviewer has finished editing the review and the ratings. The updated document is carefully discussed with the employee. Any difference in perceptions is noted. If there is any disagreement, the employee may convince the reviewer to change the review or, failing that, write a rebuttal that will be attached to the review. After changes are incorporated, the review is signed by both reviewer and employee, as well as the VP of Engineering..

---

The Review Ratings

It is well known that employee performance ratings in all organizations are inflated. This process is designed to produce realistic, provably accurate, ratings. Ratings tend to reflect how well the employee sucks up to the manager, rather than whether or not the employee generated a great product that led to lots of sales and happy customers. We have to get away from motivating employees to please the manager, and get them to please the customer.

The higher rating supercedes the lower. If the manager gives a 4 and the team gives a 7, it is a 7 and so forth. This review is a form of 360 degree feedback where the review process is designed to surface gross disparities between market perception, customer perception, company perception, team perception, manager perception, and individual employee perception of their performance. Gross disparities are rare and should be dealt with on an exception basis.

Ratings on the review are scaled from 1 to 10:

10 Trade journals are writing rave reviews about your work saying it is best in class

Historically, two teams scored a 10 with this system. The first was the original Scrum team at Easel Corporation for delivering Object Studio (ScrumMaster: John Scumniotales). The second was at IDX for delivering a new Enterprise Master Patient Index System (ScrumMaster: Mary Rettig).

9 Customers are writing rave reviews about you (must be documented in writing)

8 Exceeds expectation of the company senior management

7 Exceeds expectation of Product Owner and Team

6 Exceeds reviewers expectations

5 Meets reviewers expectations

4 Does not meet reviewers expectations

3 Does not meet development teams expectations

2 Does not meet Engineering group or company expectations

1 Customers are complaining about you

0 You are personally roasted in PC Week

Under this system, the manager can give a 4, 5, or 6. Any other rating requires outside input from the development team, the engineering group, senior management, customers, or the press. The employee can always write a rebuttal to any review and have it attached to the review as part of the human resources record.

---

Review Template

The attached document provides a template for the review.

---

Ongoing Reviews

One an initial review is written, it becomes the template for the next review. Subsequent reviews can be done easily and quickly with this template in place.

Water Cooled Laptop: Boost Your Performance!

My IBM Thinkpad T42 has a nasty habit of giving me the black screen of death. I've tried three different T42s and it happens on all of them. Tracking down the problem, it is clear that the cause is overheating. My IT Manager says I have too many programs on my machine that drive the processor too hard.

What kind of answer is that? The machine runs fine until the black screen of death appears!

The latest version of Google Earth will cause the laptop to fail every time I run it so I got serious about finding a solution. After using a cold water towel and ice I achieved success. The solution has been now optimized using an ice cold sixpack of Coke! Since my company has unlimited free supply of soft drinks, I simply get a new sixpack every four hours.

The side benefit of the water cooled laptop is that it runs screamingly fast as long as the Coke is cold. It will probably benefit all high powered laptops to watercool them!

My IT Manager thought this was so "cool" he is buying me a new Thinkpad T60. I'll keep you posted on whether water cooling the new laptop improves performance.

Scrum in 5 Minutes

When I am in Scandinavia, I often work with Softhouse, a consultancy with clients like Sony/Ericson and IKEA. They have an excellent short paper called:

Scrum in 5 Minutes

On my laptop, I can run this PDF in full screen mode as a slide show and use it for press briefings or short overviews for those not familiar with Scrum, particularly when working on "Scrum for Everybody" for non-IT implementations.

I used it in a large press conference last week in Buenos Aires and the press feedback was very positive. They said it hit them at just the right level and that my responses to questions (working through a real time Spanish interpreter) were unusually direct and to the point every time. I told them that was a lesson in Scrum transparency. We want everything to be open, clear, and direct so that teams and companies can self-organize to improve performance.


Softhouse also has a nice graphic showing the Scrum process.

JRuby - Saving programmers from their Java-only prisons!

Charles Nutter, Sun Microsystems

Ruby is basically Smalltalk for Perl programmers. However, it is getting more interesting for Java programmers. Sun has hired Charles Nutter and others to build the next generation JRuby interpreter which will run on the JVM to save "Java developers anxious to escape from their Java-only prisons."

I first got excited about Ruby at the Agile Manifesto meeting in 2001, after dining and drinking with pragmatic programmers David Thomas and Andy Hunt, authors of "Programming in Ruby." Ever since, I've done my best to avoid programming in anything else. Some of my Scrum clients have moved to Ruby for mainstream product development, and a few of the senior engineers at my company would move to Ruby in a nanosecond if it made business sense.

JRuby will allow us to run Ruby programs on the Java JVM which is essentially the core strategy I recommended to the Smalltalk community years ago to save Smalltalk.

Sutherland, Jeff. The Smalltalk Manifesto: Avoiding RoadKill on the InfoBahn. Object Magazine 9.96

Alas, they were not quick to respond. Fortunately, Ruby has come to rescue former Smalltalkers. It's definitely a survivor.

JRuby Now and Into the Future by Charles Nutter

So where has all this led? JRuby has been getting more and more attention from folks within Sun, Rubyists around the world, and especially from Java developers anxious to escape from their Java-only prisons. Our compatibility is increasing faster than before; we've had over a hundred new bugs reported in the past few weeks...almost all of them with community-contributed patches. We have added our first non-Sun team member Ola Bini, a star of the JRuby community who has proven his dedication to making Ruby on the JVM succeed. And we have started to solidify our short-term goals for the project.

The primary goal remains the same: JRuby should be as close to 100% compatible with Ruby 1.8 as possible. Today, we are doing extremely well in this department. Rails generally works without issues, and most pure Ruby applications run without modification. There's still plenty of edge cases to iron out, but we're moving very rapidly now. Getting Rails to work as well as it does is already a major achievement.

We have also started to iron out what a JRuby 1.0 release should look like. A few major points come up again and again:

• Compatibility should be such that we can safely claim "Rails is supported"
• Java integration should look like we want it to look for the future, and should be performant, lightweight, and seamless
• All major codebase refactorings should be complete; this includes a solid design for wiring up Java-based method implementations, external extensions, and IO channels
• Unicode should be supported out-of-the-box, giving Ruby code access to everything Java is capable of
• Threading should work perfectly, both for JRuby-launched threads and for "adopted" threads from outside the runtime
• Performance should be markedly improved