Don Wells

Officially his name is James Donovan 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 3 well known consultants were brought in to help. KentBeck, RonJeffries, and MartinFowler together with the Chrysler team created the ExtremeProgramming process as a result. The team members at C3 were working about 6.5 times as effectively after ExtremeProgramming was addopted.

From Chrysler he moved to Ford. He combined what he knew about TeamWork? and what he learned from the ChryslerComprehensiveCompensation at the VcapsProject for Ford. The team members at the 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. For pointing out that the 9 month schedule was impossible with a waterfall process and suggesting an Agile 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 the RationalUnifiedProcess based method called UnifiedSdm?. What he and co-conspirator ChetHendrickson created was a more 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. Ford has since revised UnifiedSdm? back to having little Agility.

He taught math for a while then took a job with InStream? Financial Services. InStream? is a small start up financial company. With a small group of programmers it is the ideal environment for agile software development. He is working on bringing in some ExtremeProgramming elements like AutomatedContinuousTesting and SimpleDesign. InStream? Financial Services went out of business because the product they sold was credit and credit became scarce in the economic down turn.

He began volunteer work at the MichiganHumaneSociety?. He was asked to answer phone calls at the free behavior help line and decided to narrow his studies to cat behavior. He is now a member of the InternationAssociationOfAnimalBehaviorConsultants?. He is still working there as a cat trainer and behavior consultant.

He was recently asked to be a BusinessAnalyst at Ford and has gone back to work there. Ford is rolling out UnifiedSdm? again with the idea of making it more Agile. It still needs some work and Don is helping his new project be even more Agile within the Ford environment.

Currently he is updating http://www.extremeprogramming.org and creating http://www.agile-process.org in the same spirit. He is creating http://www.cat-help.com based on his experiences helping people solve their cat's behavior problems.

Also see http://www.agile-process.org/donwells.html

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.

Also look at http://agile-process.org/proverbs.html

Don, Thank you very much for LispMeUnit and LispMeObjects. Awesome! -- JonathanArkell

CategoryHomePage