Don Wells

He started out as an ArtificialIntelligence guy. He built several expert systems for General Dynamics and Ford. When AI didn't live up to the hype surrounding it the AiWinter started and AI jobs became scarce. The most important things he learned while in the world of AI was about TeamWork? and how to work with DomainExperts?.

He moved into the business world by joining the ChryslerComprehensiveCompensation project. This project was not doing well so a consultant named KentBeck was brought in to help. He learned the ExtremeProgramming process while there. The team members at C3 were working about 6.5 times as effectively after KentBeck brought in ExtremeProgramming.

He combined what he learned from KentBeck with what he knew about TeamWork? at the VcapsProject for Ford. The team members at VcapsProject were working about 10 times as productively as before.

This increase in productivity was noticed by Ford management and he was assigned to a very important project called F@ST. After pointing out that the 9 month schedule was impossible with a waterfall process he was fired.

He moved back to DaimlerChrysler as part of their Advanced Development Technology Support group. He tried to incorporate some ideas about TeamWork? and ExtremeProgramming there too, but it wasn't well received. When DaimlerChrysler cut everyone's salary by about 15% he moved back to Ford.

Back at Ford he worked on adding some ExtremeProgramming values and practices to their existing RationalUnifiedProcess based method called UnifiedSdm?. What he and co-conspirator ChetHendrickson created was an agile version of UnifiedSdm?. Metrics collected by Ford showed this process to be 27% more effective. When Ford fired about half of their MIS support people he was out of a job again.

He taught math for a while then took a job with HennesseyCapital?. HennesseyCapital? is already agile so he is working on bringing in some supporting ExtremeProgramming elements like AutomatedContinuousTesting for example.

Currently he is writing a book called Software Development Proverbs based on his writings and presentations. He is also hard at work updating his website ExtremeProgrammingDotOrg to be consistent with the second edition of ExtremeProgrammingExplained.

mailto:Don(at)ExtremeProgramming.org

Object Oriented proverbs

• If it isn't fun you're doing something wrong. ItShouldSeemEasy
• The most brilliant programmer alive can not compete with 6 ordinary programmers who function as a team.
• PairProgramming is always faster.
• Anything you did today can be done tomorrow in only 15 minutes and be better.
• Who ever finds a problem knows enough to design a solution. XpDesign
• UnitTests are your safety net, never work without a net.
• Your unit TestingFramework is not a testing tool, it is a development tool.
• Whenever you can, CodeUnitTestFirst.
• Where there is a will there is a way to test. ExtremeProgrammingChallengeFourteen
• During the life of a project an automated test will save you at least 100 times the cost of creating it. Therefore, the harder the test is to write the greater your savings.
• Test suites evolve over time, if you want to have a good suite of tests next year you must start collecting them today.
• OnlyWearOneOfFourHats.
• Skipping the UnitTests takes longer. VcapsProject
• A good design has a few simple flexible objects. Try explaining your design to someone else using FourBlankCards.
• SimpleIsntEasy, it can be the hardest thing you ever did.
• DoTheSimplestThingThatCouldPossiblyWork.
• Maximize the number of good ideas, let everyone contribute. CrcCards, MovingPeopleAround, CollectiveCodeOwnership.
• MakeItWorkMakeItRightMakeItFast.
• A simple solution takes significantly less time to implement than a complex one. WaitingForSimpleIdeas to come is actually faster.
• Embrace the oddities and bad data in your system. Represent it explicitly in your design.
• Use CrcCards, they make the design clear.
• Drawing a diagram by hand will help clarify the design or show you what is wrong.
• A diagram is a painting not a photograph. If you wanted a photograph use a diskette not a UML diagram.
• Use Smalltalk as a design and prototyping language. TheSourceCodeIsTheDesign
• It's the right side of the brain that understands objects.
• Programming in Smalltalk is an art, write your programs so other people see the beauty of simple elegance too.
• UML, Booch, etc. diagrams can hide complexity, always draw an object InstanceDiagram too.
• It's always faster and cheaper to throw away complex code now, no matter how much is already invested, working or not.
• A complex system will hit the wall of unmaintainability sooner than you think.
• Estimates not based on a measurement is a guess, an estimate based on a measurement is a prediction.
• Don't read KentBeck's SmalltalkBestPracticePatterns - use it.

This page mirrored in ExtremeProgrammingRoadmap as of April 29, 2006