Martin Fowler is an independent consultant using Object Technology for business information systems. He mentors clients on the use of analysis and design techniques, patterns, and iterative project management. His is the author of Analysis Patterns:Reusable Object Models, and UML Distilled: Applying the Standard Object Modeling Language.

Source: http://www.arrakis.es/~devis/handbook/index2.html

His more recent work revolves around the new 'Agile Methods' and XP. 

His more recent works:

Refactoring: Improving the Design of Existing Code
by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts
Planning Extreme Programming
by Kent Beck, Martin Fowler
Patterns of Enterprise Application Architecture
by Martin Fowler, David Rice, Matthew Foemmel, Edward Hieatt, Robert Mee, Randy Stafford

Ward Cunningham Co-Author of CRCA Laboratory For Teaching Object-Oriented Thinking in 1989

WikiWikiWeb founder also known as Ward's Wiki

In the software community, Ward Cunningham has a reputation for being a font of ideas. He invented CRC Cards, a technique that facilitates object discovery. He invented the world's first wiki, a web-based collaborative writing tool, to facilitate the discovery and documentation of software patterns. Most recently, Cunningham is credited with being the primary inspiration behind many of the techniques of Extreme Programming.

Optional Scope Contracts Kent Beck, First Class Software Dave Cleal 

Customer	Supplier
Interprets requirements as broadly as possible, to get as much for their money as possible.	Interprets requirements as narrowly as possible, to reduce resources.
Wants the work done as quickly as possible.	Wants to finish the work on the date, to have time to get the next contract lined up.
Wants superlative quality.	Wants to invest in just enough quality so that the customer will pay.
Burned out programmers are not the customer’s problem, unless they threaten delivery.	Wants the team members to be successful on this project, and to stick around for the next one.

What we need is a different kind of contract that aligns the positions of the parties. The four variables of project management are:
· Time
· Cost
· Scope
· Quality.
The fixed scope contract specifies values for three of these variables:
· Time
· Cost
· Scope.
The other variable, quality, is in many real contracts left to flap freely in the breeze. But this doesn’t make any sense for the customer, in either the short or long term. Just talk to the ‘real’ users at the sharp end of the business. In the short term, they want something that works, and they want it soon. They’ll find a way to live without that complex report or the once-a-month function. It’s not as if they have those today. In the longer term, though, they will need changes. The software had better be maintainable.

When all four variables are specified, quality is the first one to go, because it’s least visible – or, it’s least visible before the software is delivered.

Optional Scope Contracts;

The optional scope contract retains all of these advantages, except for “predictable deliverables”. The customer has a reasonable idea of what they may get at the beginning, but reality rapidly intrudes. What they will get is inevitably different [from] what they imagined at the beginning. By giving up the illusion of control over scope at the beginning of the contract, they gain something much more valuable. Instead of getting what they wanted at the project start, they can now have what they want at the project end, after they’ve completed that learning process. What they learn to want is inevitably different from what they could have imagined at the beginning of the contract. More importantly, however, the optional scope contract makes quality a constant. The team will work, for a fixed time and price, at the quality level demanded by the customer. Nothing will be “80% completed”. 80% of the originally envisioned features might be completed, but each of them will be 100% done, as demonstrated by automated tests.

Recording requirements

We obviously still need some way to record requirements. What’s the appropriate form? One constraint unique to this contract is that we don’t expect the customer to ever deliver “the requirements”. We’ll get enough requirements to start, and more later as we learn. So, we need our requirements to be recorded in bite-sized chunks and we need the customer to prioritize those chunks. The prioritized list might be recorded in various forms, but each entry needs to describe something that the customer is willing to pay for. Some people call this a “use case”; some call it a “set of use cases”; other call it a “story”. We’ll use the word “story” here. What’s important is that: ·

• The programmers must be able to imagine how they can verify that the system actually implements the story. Automated test cases are a simple and objective mechanism for this verification. ·
• The programmers must be able to estimate how much effort this story will require, relative to all the other stories. Without estimates, the customer cannot make informed priority decisions.
• · The story must be comprehensible to the users of the system. If the customer is going to compare the priority of this story with others, they must have a feel for its value as well as its cost.
• We need to be able to code fewer or more stories to use up the time available. So smaller stories are better, because they let developers work in parallel, and we can use all of the time available. Our contract forces suppliers to deliver only software that is high quality. Partly completed stories won’t be in the delivered software: so a very large story risks getting nothing for a large investment of effort.

All of these revolve around the management of change. Imagine a project where the customer knows everything about the problem at the outset, the supplier has run a dozen similar projects before, and both sides are certain they will get no surprises during the project and are certain they won’t learn anything during the project. Such a project won’t gain anything from this form of organization, and the traditional models are fine.

But, if that isn’t the case, then something unexpected is going to happen during the project. When that happens, you want the customer and supplier to work together to deal with the problem, and you want the ability to change the shape of the project to reflect the new reality. In that case, consider an optional scope contract.

And, even more radically, an optional scope contract means you don’t even need to have an opinion about certain things. When will we be finished? After as many cycles as we choose to run. What do we ultimately want from the system? Not sure: we’ll deal with that after the obvious things have been coded. The optional scope contract lets the team make useful progress whilst deferring decisions about things they don’t yet understand very well.

The implications of developing an optional scope contract challenges conventional software development strategies. ·

• Evolutionary design- You don’t want to invest in features you won’t implement, so you can’t analyze and design the system all at once. Instead, you have to be prepared to evolve the analysis and design throughout development.
• Evolutionary delivery- You want to make money with the features you’ve implemented while you are waiting for the “optional” features to clarify themselves. You must put a minimal system into production, and continue to implement features while you support the running system.
• Internal and external quality- you expect to change the system, so you have to invest in the quality that lets you radically rework the system throughout the project without prohibitive costs for reworking and retesting.
• Automated testing- When you are finished with a feature, you must demonstrate that it is finished, and you want to ensure it doesn’t break in the future. Automated tests demonstrate features.

Contractual definitions of quality - Clearly this style of contract is only as effective as its definition of quality. A full review of how to define good measures of quality would be the subject of another, much larger, article. However, here are some pointers to ways that we believe quality can be controlled.

Most of the traditional measures of quality are based on external observation of the software. Is it sufficiently bug-free? Just count the bugs reported over three months and compare it to some target maximum bug count. The trouble with this kind of approach is that by the time you know the software is poor quality, the supplier has been paid, the individual developers have scattered to the four winds, and it’s just too late to anything about it.

So, instead, we look for internal quality measures. As we’ve implied in this article, we believe that an essential element of quality software is automated test suites that test 100% of the system’s functionality. (How do you know they cover 100%? Read the next article).

Another quality measure is how well factored the software is. The whole issue of refactoring is currently a hot topic at software development conferences. The idea is to change software purely to make it simpler, more readable and more maintainable, without changing what it actually does. It’s perfectly possible to employ a third party to review representative parcels of code to determine whether every possible refactoring has been applied. The benefits of this approach are software that is orders of magnitude easier to understand and cheaper to change: and that’s critical for the evolutionary development process we’re proposing here. See [Fowler99] for much more information about the science of refactoring.

David A. Taylor is the President of Enterprise Engines Inc. and the  Director of the Convergent Engineering Institute, both of San Mateo, California. He is an internationally recognized expert on the use of object technology in business engineering efforts. He is the author or co-author of five books on the subject, including Object Technology: A Manager's Guide (Addison-Wesley), Business Engineering with Object Technology (Wiley), and Object-Oriented Information Systems: Planning and Implementation (Wiley). His professional goal is to enable the adaptive organization, a company that dynamically models itself with intelligent objects and uses that model to execute all its critical business functions. For more information about the author and his vision, visit the company's web site at www.engines.com.

Source: http://www.arrakis.es/~devis/handbook/index2.html

Joseph William Yoder -  Home Page

professional interests cover nearly all things object-oriented, especially frameworks, patterns, business objects, Smalltalk, COM and refactoring.