Thoughts, terms, and ideas I’ve come across over the last few months.

• Write in terms of services - independent, concurrent objects behind well-defined, consistent interfaces.
• Eliminate effects between unrelated things - Design components to be self-contained, independent, and have a single well-defined purpose.
• Program close the problem domain - Design and code in your user’s language.
• Test state coverage, not code coverage - Identify and test significate program states. Just testing lines is useless.
• Test early, test Often, test automatically - Tests that run with every build are much more effective than test plans that sit on a shelf.
• Always design for concurrency - Cleaner interfaces with fewer assumptions.
• Put abstractions in code, details in metadata - Program fro the general case, and put specifics outside the compiled code base (config files).
• Keep knowledge in plain text - Won’t become obsolete.
• Use blackboards to coordinate workflow - Use to coordinate disparate facts and agents, while maintaining independence and isolation among parts.
• Use a project glossery - Single source for specific terms and vocabulary for a project.
• Find bugs once - Once a human finds a bug, it should be the last time a human finds that bug. Automated tests should check for it from then on.
• Crash early - A dead program normally does less damage than a corrupt one.
• Organize teams around functionality - Build teams the way you build code (designers + coders + testers + data modelers).
• Design to contracts - Use contracts to document and verify code does no more and no less than it claims.
• Don’t use return values for errors - Eventually a component will ignore a value and an error will silently be ignored. Dead software doesn’t lie.