''Taken from DonWells' HomePage. ThankYou Don ...''

'''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
* UnitTest''''''s 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 UnitTest''''''s 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. CrcCard''''''s, 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 CrcCard''''''s, 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.