ObjectOrientedProverbs

Last edit October 22, 2004
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.