Object Technology Jeff Sutherland

HICSS 42 Call for Papers due 15 June 2008

2008-04-04T11:01:00.006-04:00

It's time for you to get your most scintillating Agile theories
together, write a kick-ass paper that could get published in the IEEE
library and spend a week in beautiful Hawaii next January. Sound good?
Then get writing!

HICSS-42 CALL FOR PAPERS - due 15 June 2008
http://www.hicss.hawaii.edu/hicss_42/minitracks/st-asd.htm
January 5-8, 2009
Hilton Waikoloa Village Resort
Waikoloa, Big Island, Hawaii

HICSS-42 offers a unique, highly interactive and professionally
challenging environment that attendees find "very helpful -- lots of
different perspectives and ideas as a result of discussion." HICSS
sessions are comprised primarily of refereed paper presentations; the
conference does not host vendor presentations. All papers are peer
reviewed and accepted papers are published in the IEEE Digital Library.

Software Technology Minitrack
Agile Software Development: Lean, Distributed, and Scalable
(Jeff Sutherland and Gabrielle Benefield)

Agile software development processes have been influenced by best
practices in Japanese industry, particularly by lean product
development principles implemented at companies like Honda and Toyota,
and knowledge management strategies developed by Takeuchi and Nonaka, now at the Hitotsubashi Business School in Japan, and Peter Senge at
MIT. This Minitrack will focus on advancing the state of the art or
presenting innovative ideas related to agile methods, individual
practices and tools.

Accepted papers will potentially enrich the body of knowledge and
influence the framework of thought in the field by investigating Agile
methods in a rigorous fashion.

We are open to research papers on multiple aspects of agile methods,
particularly those that bring best practices in knowledge management
and lean development to scalable, distributed, and outsourced Scrum,
eXtreme Programming (XP), and other agile practices. Topics include:

1. Research on existing or new methodologies and approaches: informal
modeling techniques and practices, adapting/trimming existing methods,
and new product/project planning techniques
2. Research on existing or new techniques or practices: pairing,
war-rooms, test-first design, paper-based prototyping, early
acceptance test driven development, exploratory testing, refactoring,
or others.
3. Research on special topics or tools: configuration and resource
management, testing, project steering, user involvement, design for
agility, virtual teams or others.
4. Research on integrating ideas from other fields, e.g. interaction
design, requirements engineering, cognitive science, organizational
psychology, usability testing, software security, into agile processes.
5. Research studies of development teams using ethnographic or social
6. Research on agile software engineering economics.
7. Quantitative and qualitative studies of agile methods, practices,
and tools.
8. Research on agile compliance and cost benefits within CMMI, ISO
9000, and FDA certified development projects.

Papers are particularly relevant when agile process implementations
are shown to produce quantitative and qualitative benefits on
distributed, outsourced, large, or standards compliant software
development projects which have been previously been viewed
(erroneously) as unsuited for agile development.

To submit papers and read more about the conference please go to:
http://www.hicss.hawaii.edu/hicss_42/minitracks/st-asd.htm

Jeff Sutherland
Scrum, Inc.
332 Congress St., 3rd Floor
Boston, MA 02210

Gabrielle Benefield
Scrum Training Institute
Mountain View,
CA 94040
Email: gabriellebenefield@yahoo.com

Agility and Organizational Patterns

2008-02-02T15:05:00.002-05:00

In the early days of what we now know as Agile processes, Mike Beedle was influenced by the online description of Scrum, implemented the process in his own company, and led the effort to drive Scrum through the Pattern Languages of Programming Design conferences. This made Scrum the first (and only) formal organizational pattern that describes a complete Agile process. One of the patterns books contains the Scrum pattern:

M. Beedle, M. Devos, Y. Sharon, K. Schwaber, and J. Sutherland, "Scrum: A Pattern Language for Hyperproductive Software Development," in Pattern Languages of Program Design. vol. 4, N. Harrison, Ed. Boston: Addison-Wesley, 1999, pp. 637-651.

Recent work by Jim Coplien shows that Scrum is deceptively simply while compressing a complex array of organizational patterns in his book, "Organizational Patterns in Agile Software Development." Jim was surprised when he found that Scrum compresses at least 33 patterns from his book into a concept that can be explained in 2 minutes. It takes over 60 pages of rather dense text to describe these patterns.

One of Scrum's design goals was to encapsulate best practices from 40 years of software development into a process that was simple enough for the average IT worker to use for development in less than 2 days of startup time. Jim's research shows that we did a good job of accomplishing that goal. You can download a copy of the complete Scrum pattern as it is part of a draft of "The Scrum Papers."

Click here for Jim's presentation on Scrum as a set of patterns.

Agile Software Development: Lean, Distributed, and Scalable

2008-01-08T14:55:00.000-05:00

HICSS 2008 Agile MiniTrack
Co-Chairs: Jeff Sutherland and Hubert Smits
HICSS 41, January 7-10, 2008 - Hilton Waikoloa Village Resort
Waikoloa, Big Island, Hawaii

If you are in Hawaii now, congratulations! If not, eat your heart out ...

ST 1 Thursday; Kona 3; 8:00 � 9:30

This session has three papers. Authors will have 15 minutes for presentation and 15 minutes for discussion. Papers will be presented in the following order.

Bridge Methods: Complementary Steps Integrating Agile Development Tools and Methods with Formal Process Methodologies
Stephen J. Cohen and William H. Money
Rolling Out Agile in a Large Enterprise
Gabrielle Benefield
Great Scrums Need Great Product Owners: Unbounded Collaboration and Collective Product Ownership (in competition for best paper)
Ken H. Judy and Ilio Krumins-Beens

ST 2 Thursday; Kona 3; 10:00 � 11:30'

This session has four papers. Authors will have 15 minutes for presentation and 10 minutes for discussion.

Effects of Agile Methods on Website Quality for Electronic Commerce
David F. Rico
A Case Study: Introducing eXtreme Programming in a US Government System Development Project
Ann Fruhling, Patrick McDonald, and Christopher Dunbar
Retrofitting Cyber Physical Systems for Survivability through External Coordination
Kun Xiao, Shangping Ren, and Kevin Kwiat
Scrum and CMMI Level 5: The Magic Potion for Code Warriors
Jeff Sutherland, Carsten Ruseng Jakobsen, and Kent Johnson

Douglas Crockford on The State of Ajax

2007-11-14T11:10:00.001-05:00

In a recent Yahoo YUI video, Yahoo's Douglas Crockford gives an overview of the state of Ajax application development on the Web, and points to ways in which the Web can improve. Advertisement

Douglas Crockford, inventor of the JSON data exchange format, and Yahoo's chief DHTML evangelist, presents an overview of the State of Ajax and client-side Web development. Among the topics he discusses are Java, the flaws and benefits of JavaScript, why CSS should be replaced, why mashups are significant, and what can be done about Web technologies, such as HTML and JavaScript, that saw their last major updates in 1999.

Kleiner Perkins gets real on global warming

2007-10-31T20:56:00.000-04:00

John Doerr gave a great talk on climate change at the recent TED conference. Check out "Seeking salvation and profit in greentech."

-----
John Doerr, a partner in famed VC firm Kleiner Perkins Caufield & Byers, made upwards of $1 billion picking dot-com stars like Amazon, Google, Compaq and Netscape. (He also picked some flops, like Go Corporation and the scandal-ridden MyCFO.com.) He was famously quoted saying, "The Internet is the greatest legal creation of wealth in history," right before the dot-com crash.

But now he's back, warning that carbon-dioxide-sputtering, gas-powered capitalism will destroy us all, and that going green may be the "biggest economic opportunity of the 21st century." So Kleiner Perkins has invested $200 million in so-called greentech, a combination of startups that are pioneering alternative energy, waste remediation and other schemes to prevent the coming environmental calamity. But Doerr is afraid that it might be too little, too late.

"[John Doerr] is, by all accounts, the most influential venture capitalist of his generation." Fast Company

Why Time Sheets are Lame ...

2007-10-07T14:29:00.000-04:00

Programmer time vs. Quality Software Score. Totally uncorrelated!

Actually time sheets are worse than lame:
* they demotivate developers
* 10-15% loss of productivity is the minimum
* developers have to fake the time to fill them out properly
* erroneous data is used for reporting and management makes bad decisions
* customers are deceived
* they have nothing to do with quality code production
* they focus the whole organization on phony data instead of production

Nevertheless, this is not enough for many managers to give up time sheets. Just like the waterfall process, there is a psychological dependency so strong, it is as if they are on drugs.

However, the situation is even worse. Most management has completely wrong information in their head and thus continually make bad decisions. One of my students recently said to me, "You mean everything my manager told me is wrong!"

Yes, Jose, everything your manager ever told you is wrong:
* there is no correlation between developer time and software production
* there is no correlation between time spent and quality of code
* there is no relationship between "quality people" and code production

The only correlation between developer time and quality production code is the quality story points measured as a deliverable for a specific team.

Research over many years at Yale University provides some of the best data on this topic - see Joel on Software
:
* for a single project worst/best coding times are 1/10
* across many projects worst/best coding times are 1/25
* the ratios above are the same for the worst and best Yale students
* the quality of the code produced is completely independent of time spent

For some reason, many development managers makes decisions without any data at all on this issue and their assumptions are completely out of reality.

Tom Poppendieck told me recently a competent manager actually did some research on his XP teams to see what number of hours per week produced the maximum amount of quality production code. After trying shorter weeks and overtime weeks, the best number of hours for teams to produce the most quality code was a 16 hour work week!

Trust me, you need to dump those lame time sheets and get focused on real software production before an Agile competitor puts you out of business!

Scrum and CMMI Level 5: A Magic Potion for Code Warriors

2007-09-05T14:18:00.000-04:00

An earlier blog item commented on the dramatic advantages of using Scrum with CMMI, particularly with a CMMI Level 5 company. See Scrum supports CMMI Level 5.

At the Agile 2007 Conference in Washington, D.C., an experience report was presented on the results of introducing Scrum into a CMMI Level 5 environment to replace waterfall projects for large defense and healthcare contracts. See Scrum and CMMI Level 5: A Magic Potion for Code Warriors. The paper was written by:

Jeff Sutherland, Ph.D. - Co-Creator of Scrum
Carsten Jakobsen - Systematic Software Engineering Process Leader
Kent Johnson - CMMI Level 5 Auditor

Systematic Software Engineering is a company which executes the waterfall process better than almost all companies in the world, with an ontime, on budget delivery rate of over 95% with estimates within 10% of actuals. The Scrum results were extraordinary, similar to introducing a team of Toyota consultants into a manufacturing plant. This was the result of driving the Scrum implemenation by lean principles which assured a disciplined and measured introduction of Agile practice.

- Productivity doubled in less than six months reducing total project costs by 50%.
- Defects were reduced by 40% in all Scrum projects (despite the fact this company already had one of the lowest defect rates in the world.)
- Planning costs were reduced by about 80%.
- User satisfaction and developer satifaction were much higher than comparable waterfall implementations.
- Projects were linearly scalable, something never seen before. The productivity of individual developers remains the same as the project increases in size.

The data in this study is some of the best in the industry and puts to rest the argument about whether the waterfall is preferable in some cases. The waterfall will always be less productive with higher defects on any project compared to a well executed Scrum.

Systematic Software engineering has revised its standard processes to use Scrum everywhere. See Scrum and CMMI Level 5: A Magic Potion for Code Warriors.

Agile 2007 Video Contest 1st Place: Developer Abuse

2007-08-20T19:31:00.000-04:00

At the Google party at Agile 2007 we all voted (screamed) for the best Agile video advertisement. Developer Abuse won easily.

Camp Scrum: A Powerful New Concept to Accelerate your Agile Program

2007-08-10T01:15:00.000-04:00

Looking for a powerful way forward into the world of Agile development? Whether you're just getting started or looking for ideas that can improve your current Agile implementation, you don't want to miss this opportunity to learn from the world's top experts in Scrum and Agile software development.

Imagine having a whole week together with four of the most authoritative personalities in Agile software development today... Not only a week of seminars, but a week of living with the experts, and of informal discussions of everyday practical problems of project management... Imagine gaining deep insights into the fundamentals of Scrum and Agile that could make all the difference in the world on your current project... Imagine being able to discuss these issues with others like you who bring their experiences to this event... Then imagine it all taking place in a beautiful rural Swedish setting, surrounded by nature...

If you can imagine this, you can imagine Camp Scrum.

Hawaii International Conference on Soft ware Systems 2008: Call for Papers - due 15 June 2007

2007-06-09T02:34:00.000-04:00

Get your papers in by 15 June 2007 - don't miss Hawaii in January 2008!

Agile Software Development: Lean, Distributed, and Scalable
(Jeff Sutherland and Hubert Smits)

Agile software development processes have been influenced by best practices in Japanese industry, particularly by lean product development principles implemented at companies like Honda and Toyota, and knowledge management strategies developed by Takeuchi and Nonaka, now at the Hitotsubashi Business School in Japan, and Peter Senge at MIT. This Minitrack will focus on advancing the state of the art or presenting innovative ideas related to agile methods, individual practices and tools. Accepted papers will potentially enrich the body of knowledge and influence the framework of thought in the field by investigating Agile methods in a rigorous fashion.

We are open to research papers on multiple aspects of agile methods, particularly those that bring best practices in knowledge management and lean development to scalable, distributed, and outsourced Scrum, eXtreme Programming (XP), and other agile practices. Topics include:

Research on existing or new methodologies and approaches: informal modeling techniques and practices, adapting/trimming existing methods, and new product/project planning techniques

Research on existing or new techniques or practices: pairing, war-rooms, test-first design, paper-based prototyping, early acceptance test driven development, exploratory testing, refactoring, or others.

Research on special topics or tools: configuration and resource management, testing, project steering, user involvement, design for agility, virtual teams or others.

Research on integrating ideas from other fields, e.g. interaction design, requirements engineering, cognitive science, organizational psychology, usability testing, software security, into agile processes.

Research studies of development teams using ethnographic or social research techniques.

Research on agile software engineering economics.

Quantitative and qualitative studies of agile methods, practices, and tools.

Research on agile compliance and cost benefits within CMMI, ISO 9000, and FDA certified development projects.

Papers are particularly relevant when agile process implementations are shown to produce quantitative and qualitative benefits on distributed, outsourced, large, or standards compliant software development projects which have been previously been viewed (erroneously) as unsuited for agile development.

Jeff Sutherland (primary contact)
Chief Technology Officer and Worldwide Scrum Consulting Practice Manager
PatientKeeper Inc.
275 Washington St., 2nd Floor
Newton MA 02458
Tel: (617) 987-0394
Email: jeff.sutherland@computer.org

Hubert Smits
Services Dept
Rally Software Development
3333 Walnut Street
Boulder, CO 80301
Email: Hubert.Smits@rallydev.com

Graduation Time: MIT PhD Thesis uses cheap supercomputer

2007-06-05T09:38:00.001-04:00

All at Once Computing
.........|....................|..................|..................|..................|

.........|....................|..................|

Dr. Andrew Sutherland will be awarded his Ph.D. degree at MIT on 7 June 2007. He needed a supercomputer to complete thesis thesis and his approach was to link eight HP a6030m dual processor AMD systems together to parallel process new mathematical techniques that will be useful for encryption. Breaking through a previous unsolved problem required developing algorithms that ran thousands of times faster than previous approachs. A calculation that required 15 days on a Sun Sparcstation4 now takes less than 3 seconds on a PC.

I bought one of these inexpensive HP systems to test it out and is extremely fast, almost totally silent, and produces almost no heat compared to the Dell dual processor Intel system sitting next to it. I can see why Dell is "feeling the heat" from the competition. Suffice to say, this HP is blazingly fast compared to my watercooled IBM Thinkpad T42 which I have relegated to the dustbin of computing history. I'm thinking about buying a couple more of the HP systems. For the orginal price of my Dell workstation, I could have a eight system supercomputer lab.

For those of you who are math geeks, here is the thesis abstract:

Order Computations in Generic Groups
by Andrew V. Sutherland
Submitted to the Department of Mathematics on May 16, 2007, in partial fulfillment of the requirements for the degree of DOCTOR OF PHILOSOPHY
For PDF of thesis click here.

Abstract

We consider the problem of computing the order of an element in a generic group. This is known to require exponential time. The two standard algorithms, Pollard�s rho method and Shanks� baby-steps giant-steps technique, both use Θ (N^1/2) group operations to compute |?| = N, and a lower bound of Ω (N^1/2) has been conjectured. We disprove this conjecture, presenting a generic algorithm with complexity o N^1/2) in any group. The worst case occurs when G is a cyclic group of (unknown) prime order, but for approximately half the integers N ε [0,M], the complexity is O (N^1/3).

We prove that a generic algorithm can perform any number of order computations in near linear time, plus the cost of a single order computation with N = #955;(G), where λ(G) is the group exponent (without knowledge of λ(G)). We show that in abelian groups, λ(G) can be computed for the same cost, and also consider some non-abelian cases.

We then use λ(G) to compute the structure of an abelian group. Given an O (N^2-ε) bound on |G| = N, we can compute group structure in o (N^1/2) group operations for all but a small set of pathological cases. The complexity is essentially that of an order computation on a single random element. A lower bound of Ω N^1/2) had been assumed, based on a similar bound for the discrete logarithm problem.

We apply these results to compute the ideal class groups of imaginary quadratic number fields, a standard test case for generic algorithms. The record class group computation by a generic algorithm, for discriminant ?4(1030 + 1), involved some 240 million group operations over the course of 15 days on a Sun SparcStation4. We accomplish the same task using 1/1000th the group operations, taking less than 3 seconds on a PC. Comparisons with non-generic algorithms for class group computation are also favorable in many cases. We successfully computed several class groups with discriminants containing more than 100 digits. These are believed to be the largest class groups ever computed.

Scrum World Tour T-Shirt

2007-05-23T10:02:00.000-04:00

Thanks to �rjan Hillbom CPG we now have a Scrum World Tour T-Shirt produced by Trifork in Denmark. �rjan is a rock group/motorcycle gang video expert who attended a Certified ScrumMaster training by me and Jens Ostergaard in Copenhagen recently. He said Scrum really "rocks" and it is definitely "faster, better, cooler" and must have a world class T-shirt which he designed for free.

A Type C Scrum Danish company produces really nice T-shirts so I asked them to produce this one. It costs about $30 plus a few dollars for shipping. Get your Scrum World Tour T-Shirt at Trifork.

Regenerative Build Tools

2007-05-16T11:34:00.000-04:00

Regenerative Build Tools
by Michael Feathers, May 15, 2007

Summary
Dust off an old computer and put it to work.

I think that when people look back at the way we program today, one of the things that they'll be amazed at is the fact that we have so much computing power but we don't do much with it.

Seriously, how many computers do you have? If you're like me you have a least a couple of stray ones sitting around the office, and they aren't doing anything. What a waste. And, it's only going to get worse as multicore processors become more prevalent.

When I first heard of continuous integration, way back in the day, I misunderstood it. I thought that some computer someplace was going to build my project continuously. That is, regardless of whether I or anyone else had checked in. Silly? Perhaps. But, wasteful? I don't think so, the computer is running anyway. It might as well work.

A while back, I visited a C++ team that had found a wonderful use for a spare computer. They set it up to build continuously. Then they did something fascinating. They created a script that went into their code and commented out a single #include. Then it built their project. If the build and the tests passed, the script deleted the include. If it didn't, the script uncommented the include and went on to the next one. Yes, it took quite a while to march through the code, but with that build running continuously in the background, they were able to eliminate a large number of superfluous dependencies. Their build got better.

That script that they wrote is an example of something I call a regenerative build tool. There are others. Jester is a regenerative build tool which uses mutation testing to find problems. It changes your code in subtle ways and runs your tests to see whether they still pass. If they do, you either don't have the tests you need to have, or you could have code which is really doesn't contribute to your results at all -- zombie code. Guantanamo is another regenerative build tool, a rather severe one. It deletes all code that isn't covered by a set of tests.

Deep Agile: A Dialogue Between Scrum and XP

2007-04-13T14:01:00.000-04:00

Photo from cover of Crosstalk, Apr 2007

Spend two days with two signatories of the Agile Manifesto - Jeff Sutherland, Co-Creator of Scrum, and Ron Jeffries, XP author and consultant.

You wouldn't want to miss a two day deep dive into Agile: Scrum, Extreme Programming(XP) and Lean steps to software development success. Not to mention how to get Scrum and XP working together ...

When: April 28 and 29th, 2007
Where: MIT Tang Center/E51-345, Cambridge, MA

Register here. All proceeds go to the Boston chapter of the ACM.

Scrum Montage

2007-03-16T10:39:00.000-04:00

Montage-a-Google

Montage-a-google is a simple web-based app that uses Google's image search to generate a large gridded montage of images based on keywords (search terms) entered by the user. Not only an interesting way of browsing the net, it can also be used to create desktop pictures or even posters.

The Scrum montage was created by setting Scrum as the keyword for a Montage-a-Google search.

Get an Experienced Developer on the Test Team

2007-03-04T14:59:00.001-05:00

In 1993, at Easel Corporation, we went to the local university and hired their best Master of Computer Science graduate to join the test team and focus 100% on automation. This was one of the decisions that put the first Scrum into a hyperproductive state where we delivered software so fast, the management, sales, and marketing people asked us to slow down.

Alberto Savoia proposes the same thing in his recent blog posting and his proposed job description is below. Click here to read the full post that makes the case for an experienced developer on the test team.

Agitating Thoughts & Ideas
Developer Testing Masters and Brain Surgeons
by Alberto Savoia
February 26, 2007

Developer Testing Master

This is a high-visibility, high-impact, senior software development position, reporting to the VP of Software Engineering at Company ABC. The successful candidate will help our software engineering organization bridge the gap between development and QA by providing developers with the infrastructure, tools, training, and support necessary to be successful at developer/unit testing.

Job Requirements:

[Should start with the organization�s standard requirements for non-junior software developers. Remember, this should not be an entry-level or junior position. This person has to be at least as good as other developers � ideally better than most of them since the DTM will often have to understand, clean-up, and make testable some of the un-testable code the other developers have created.]

Must have demonstrated passion for, and experience in, developer testing. Should be extremely familiar with continuous integration and testing tools and frameworks (CruiseControl, xUnit, code-coverage tools, etc.)

Must have leadership ability to evangelize, motivate, and train developers in the art and science of unit testing.

Job Responsibilities

Help to set-up a software development environment that enables continuous integration and testing. Environment must support automated hourly and nightly builds. The former must run smoke tests and the latter the full battery of developer tests. Might have to implement distributed testing framework to allow parallel test execution.

Analyze the existing code base and recommend and/or implement re-designs and refactorings to make the code base testable.

Extend and customize xUnit framework to standardize and simplify unit test writing for the other developers. Extend the �TestCase� class by creating �CompanyABCTestCase� and maintain the latter. Implement initial set of mocks, test fixtures, and other set-up methods to enable other developers to write true unit tests that don�t depend on external system resources.

Create and deliver basic unit testing training material to educate all developers in the art and science of unit testing.

Work with the team to decide on developer testing metrics and objectives. Create, maintain, and publish a developer-testing dashboard to track those objectives.

Ruby Implementations Shootout

2007-02-26T15:36:00.000-05:00

Antonio Cangiano reported on Ruby benchmarks recently:

Many brilliant developers are working on improving the current implementation of Ruby and on creating alternatives. I was curious about their current respective speeds, so I installed and ran some benchmarks for the most popular implementations. In this article, I�m sharing the results for the community to see...

Benchmark Environment

My tests were conducted on an AMD Athlon� 64 3500+ processor, with 1 GB of RAM.

The tested Ruby implementations were:

* Ruby 1.8.5-p12 stable on Linux;
* Ruby 1.8.5-p12 stable on Windows Vista;
* Ruby 1.9 on Linux;
* JRuby on Linux;
* Rubinius on Linux;
* Cardinal on Linux;
* Gardens Point Ruby .NET Beta 0.6 on Windows Vista;

The operating system that was used for all � but Ruby.NET � is Ubuntu 6.10 (for x86). Ruby.NET currently runs on Microsoft Windows only, therefore I�ve used Vista with the .NET Framework 2.0 and have also run Ruby 1.8.5-p12 on Windows as a means of having a more direct comparison with Ruby.NET.

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

2006-11-30T15:58:00.000-05:00

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

2006-11-29T12:40:00.001-05:00

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!

2006-11-20T08:12:00.000-05:00

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

2006-11-19T13:19:00.000-05:00

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!

2006-11-08T10:47:00.000-05:00

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

InfoQ and the Roots of Scrum

2006-09-24T16:34:00.000-04:00

The JAOO Conference is coming up next week in Denmark. This is one of the leading annual software developer conferences and highly recommended. Last year, I presented at the JAOO conference on the Roots of Scrum. It was a great conference with about 900 Java and .NET developers in attendance.

InfoQ has just put up a video of the entire Roots of Scrum presentation along with slides that synchronize with the video. Very cool!

The Roots of Scrum marketing pitch on InfoQ concerning Kent Beck, Scrum, and XP is somewhat exaggerated. In the presentation, I discuss the email Kent sent me in 1995 when he requested materials on Scrum. He was certainly aware of Scrum and particularly the Takeuchi and Nonaka 1996 Harvard Business Review paper mentioned in the Roots of Scrum video. XP, however, focuses on engineering practices which are quite useful to Scrum teams. While the first Scrum team used all of what became XP engineering practices in some form, an early decision was made with Ken Schwaber to focus industry-wide rollout of Scrum on team, project management, and scaling issues. As a result, Scrum as a way to manage and scale teams is nicely complementary, yet not overlapping, to XP engineering practices. The highest performing development teams tend to use both Scrum and XP at once as you will notice in my recent paper on the SirsiDynix project.

Next Wednesday at JAOO, I will talk about Scrum Tuning. How do you make your Scrum implementation better and what are best practices observed when watching hyperproductive Scrum teams in action? This will be followed by a two day Scrum certification course at the conference. This CSM course has been sold out for months so those of you who would like to become a Certified ScrumMaster in Denmark should take a look at the October 25-26 CSM Course in Aarhus which will follow the JAOO conference. Contact Anne Sophie Bille at EOS: asb@eos.dk.

Type C Scrum: The Agile Enterprise

2006-08-14T10:46:00.000-04:00

At the Agile 2005 conference in Denver, I presented a research paper on a multi-team, multi-product Scrum which has a daily Scrum-of-Scrums meetings and a weekly MetaScrum where all Sprints are started, stopped, or changed by a broad base of company stakeholders. Thus the entire company runs as a Scrum.

Sutherland, Jeff. Future of Scrum: Parallel Pipelining of Sprints in Complex Projects. Agile 2005, Denver, CO. IEEE (in press)

The thrust of a Type C Scrum is to enable the entire enterprise to be Agile. Better software and faster development may not be enough to win in the marketplace. You need a Type C Scrum to turn your company into a competitive monster. Check out the slides from my presentation.

Since the IEEE format limits text to 10 pages, I have written up a more detailed version which will be published real soon in a short book called "The Scrum Papers." Let me know if you are interested in the long paper and I will send you a draft of the book (but only if you agree to give me feedback on how to make the paper better)!

No Silver Bullet: Essence and Accidents of Software Engineering

2006-06-26T16:19:00.000-04:00

Fred Brooks comments:

Much of present-day software-acquisition procedure rests upon the assumption that one can specify a satisfactory system in advance, get bids for its construction, have it built, and install it. I think this assumption is fundamentally wrong, and that many software-acquisition problems spring from that fallacy. Hence, they cannot be fixed without fundamental revision--revision that provides for iterative development and specification of prototypes and products.

Incremental development--grow, don't build, software. I still remember the jolt I felt in 1958 when I first heard a friend talk about building a program, as opposed to writing one. In a flash he broadened my whole view of the software process. The metaphor shift was powerful, and accurate. Today we understand how like other building processes the construction of software is, and we freely use other elements of the metaphor, such as specifications, assembly of components, and scaffolding.

The building metaphor has outlived its usefulness. It is time to change again. If, as I believe, the conceptual structures we construct today are too complicated to be specified accurately in advance, and too complex to be built faultlessly, then we must take a radically different approach.

Let us turn nature and study complexity in living things, instead of just the dead works of man. Here we find constructs whose complexities thrill us with awe. The brain alone is intricate beyond mapping, powerful beyond imitation, rich in diversity, self-protecting, and selfrenewing. The secret is that it is grown, not built.

So it must be with our software-systems. Some years ago Harlan Mills proposed that any software system should be grown by incremental development. [10] That is, the system should first be made to run, even if it does nothing useful except call the proper set of dummy subprograms. Then, bit by bit, it should be fleshed out, with the subprograms in turn being developed--into actions or calls to empty stubs in the level below.

I have seen most dramatic results since I began urging this technique on the project builders in my Software Engineering Laboratory class. Nothing in the past decade has so radically changed my own practice, or its effectiveness. The approach necessitates top-down design, for it is a top-down growing of the software. It allows easy backtracking. It lends itself to early prototypes. Each added function and new provision for more complex data or circumstances grows organically out of what is already there.

The morale effects are startling. Enthusiasm jumps when there is a running system, even a simple one. Efforts redouble when the first picture from a new graphics software system appears on the screen, even if it is only a rectangle. One always has, at every stage in the process, a working system. I find that teams can grow much more complex entities in four months than they can build.

Brooks, Frederick P., "No Silver Bullet: Essence and Accidents of Software Engineering," Computer, Vol. 20, No. 4 (April 1987) pp. 10-19.