Agile DNA

Henry Ford built his early automobiles using scientific management techniques. Every production step was optimized for return on investment. Cars were shipped directly from the factory to the dealer without testing them. The focus was on efficient, not quality production. As the auto industry grew factories added testing and repair stations at the end of the line to catch defects before the customers did. It was a helpful innovation. Quality assurance became focused on that final phase. When defects were found components were disassembled and fixed. The cost of this re-work was high.

Parallels can be found in how most of the software industry builds software today. Programs are either released to the customer for testing, or they are tested as the last step before release to the customer. And much of the current focus of quality assurance is on finding defects at the end. Is it reassuring that we are following the same path as the automotive industry before 1970?

Certainly if we do a good job of testing at the end, many of the defects will be caught. Testing cars at the end does find the defects. But since a mass-production factory produces in large batches, many cars are built with the same defect before the defect is detected at the end. Consequently many cars often need to be re-worked because of the same defect. When cycle time between error, detection, & correction is long it causes repeated errors to occur before correction. Now that is expensive!

Could this be why 80% of software development costs are spent on defect removal? If we wait until the end of a month-long cycle to test, programmers will introduce similar kinds of defects across the system. Repeated defects in software occur when communication with the customer breaks down causing multiple wrong features to be built; when wrong assumptions are propagated; or when programmers don't share information among themselves and multiple programmers make the same mistake. These defects show the limitations of long cycle times. That is the approach of Scientific Project Management.

I'll talk about how Lean Manufacturing does it in the next post ...

$59.5 Billion is wasted every year! The U.S. gross domestic product loses 0.6% a year because of software defects. Currently, over half of all errors are not found until 'downstream' or during post-sale software use. This occurs even though vendors already spend 80% of development costs on defect removal.

The software industry is becoming increasingly interested in removing defects after the defects are created. A focus on defect removal sounds like a good idea. But what if the defects are not created in the first place? What would that be worth? Is it realistic to suggest that software can be built without defects? Teams using Lean Software Development are demonstrating that it can be done. To see what we mean by Lean, let's start with what is not Lean. We'll save that for the next post ...

Most J2EE development is in DP style That does not mean that you cannot do Object Oriented J2EE. But what people do with a language creates the language culture. Perhaps some people could build OO programs in a culture of Data Processing (DP), but it will always be fighting against the norm.

You can certainly build OO designs with java. Lot of people do. Often however, requirements are presented in terms of DP vocabulary. This makes building it in OO more difficult for the users to understand. DP is encouraged when requirements:

• Specify the screens
• Specify the DB schema
• Specify the data fields, flags, switches, and codes
• Specify the data transformations.

Fitting that into an OO mold is another impedance mismatch.

OO requirements would:

• talk in Business terms
• Name the concepts involved (Classes)
• Iterate furiously to refine understanding, and reduce concepts to a minimum
• define and place behavior (not data) into and among the classes

This requires business uses to talk in business language. However, I'm noticing that most Business users are now talking in terms of data and processing. Not in their own native business language.
Many Business users speak DP. They expect DP solutions.

So, to really do OO, the upstream expectation need to be broadened. The business users need to speak in their native language of concepts again. This is a switch in culture. And will be difficult.

The first step is for us Java folks to understand that what we have often been delivering is not OO. But at the core of most J2EE systems are data structures and processes, hence DP-style. Much of the common literature in Java has encouraged this. The J2EE blue prints, Struts, Entity Beans, etc. These all encourage a DP approach. So to do OO in J2EE, is often swimming against a powerful set of fundamental assumptions, and frameworks. Thats why I'm exploring the Ruby language and culture. The assumptions in Ruby are tilted heavily toward Object Orientation.

I worry that trying to do OO in J2EE will often make one a frustrated outsider.

Data Processing style also involves the use of:

• data structures (called Beans) that have only data with gettters/setters.
• Util classes to operate on the Data Structures
• Managers, Services, and Helpers, etc, that do all the real processing.
• And global public constants that are shared by multiple algorithms scattered across the code base