Bob Martin’s Three Laws of TDD

Bob Martin describes Test-Driven Development using these three simple rules:

  1. Do not write production code unless it is to make a failing unit test pass.
  2. Do not write more of a unit test than is sufficient to fail, and build failures are failures.
  3. Do not write more production code than is sufficient to pass the one failing unit test.

Even though this sounds restrictive, it is a very productive and fun way to develop software.

Fonte: http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd

Joel Spolsky on hiring

Two of the biggest challenges in technical hiring are identifying people who are smart but don’t get things done and people who get things done but aren’t smart. A company in a competitive industry needs to avoid hiring both classes of people.

“People who are smart but don’t get things done often have PhDs and work in big companies where nobody listens to them because they are completely impractical,” explains Spolsky.

“People who get things done but are not smart will do stupid things, seemingly without thinking about them, and somebody else will have to come clean up their mess later.”

Tratto da: How would you move mount Fuji? di William Poundstone.

Douglas Crockford on features

We see a lot of feature-driven product design in which the cost of features is not properly accounted. Features can have a negative value to consumers because they make the products more difficult to understand and use.

We are finding that people like products that just work. It turns out that designs that just work are much harder to produce than designs that assemble long lists of features.

Features have a specification cost, a design cost, and a development cost. There is a testing cost and a reliability cost. The more features there are, the more likely one will develop problems or will interact badly with another.