Andrew Hunt

“If you work closely with your users, sharing their expectations and communicating what you're doing, then there will be few surprises when the project gets delivered. This is a BAD THING. Try to surprise your users. Not scare them, mind you, but /delight/ them.”

“Names are deeply meaningful to your brain, and misleading names add chaos to your code.”

“More testing should be done automatically. It's important to note that by "automatically" we meant that the test /results/ are interpreted automatically as well.”

“In an article in the April 1999 CACM, Robert Glass summarizes research that seems to indicate that, while code inspection is effective, conducting reviews in meetings is not.”

“In addition, build dependencies may not be the same as test dependencies, and you may need separate hierarchies.”

“There is a simple marketing trick that helps teams communicate as one: generate a brand. When you start a project, come up with a name for it, ideally something off-the-wall. (In the past, we've named projects after things such as killer parrots that prey on sheep, optical illusions, and mythical cities.) ...Use your team's name liberally when talking with people. It sounds silly, but it gives your team an identity to build on, and the world something memorable to associate with your work.”

“Just be aware that you reach a point of diminishing, or even negative, returns as the specifications get more and more detailed.”

“Providing a comfortable transition through familiar metaphors is one way to help get buy-in.”

“Documenting the reasons behind requirements will give your team invaluable information when making daily implementation decisions.”

“...maintaining good regression tests is the key to refactoring with confidence.”

“Don't be a slave to history. Don't let existing code dictate future code. All code can be replaced if it is no longer appropriate. Even within one program, don't let what you've already done constrain what you do next -- be ready to refactor... This decision may impact the project schedule. The assumption is that the impact will be less than the cost of /not/ making the change.”

“The editor will be an extension of your hand; the keys will sing as they slice their way through text and thought.”

“Don't gloss over a routine or piece of code involved in the bug because you "know" it works. Prove it. Prove it in this context, with this data, with these boundary conditions.”