Object Oriented Proverbs

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
• 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.