The facet I admired most about the Microsoft corporate culture was an unrelenting desire to learn and improve. Every time I needed a support group (be it IT or dining) I would receive prompt service and a post-mortem survey to gauge my satisfaction. Likewise, the relocation department and intern organization also placed emphasis on similar data. This data driven success measurement was pervasive throughout the company. I strongly believe this empirical emphasis has paid dividends at the corporation (similiar mentalities can be found at Amazon and other corporations).

Microsoft Research applied this notion to the study of  software engineering as a whole In Exploding Software-Engineering Myths,   MSR explores a number of research projects carried out with the intent of applying cold empirical evidence to the field of sofware development.

A few take aways:

1. More Isn’t Always Better
   1. “It is more beneficial to achieve higher code coverage of more complex code than to test less complex code at an equivalent level. ”
2. Write Test Code First
   1. “The research team found was that the Test Driven Development (TDD) teams produced code that was 60 to 90 percent better in terms of defect density than non-TDD teams. They also discovered that TDD teams took longer to complete their projects—15 to 35 percent longer.”
3. Proving the Utility of Assertions
   1. “The team observed a definite negative correlation: more assertions and code verifications means fewer bugs.”
   2. And interestingly, “The research team believes that enforcing the use of assertions would not work well; rather, there needs to be a culture of using assertions in order to produce the desired results.”
4. Organization Structure Does Matter – a lot
   1. “Organizational metrics, which are not related to the code, can predict software failure-proneness with a precision and recall of 85 percent.”
5. Geographical Distance Doesn’t Matter – much
   1. Researchers asked engineers who’d they’d prefer to talk to when faced with issues: “Most people preferred to talk to someone from their own organization 4,000 miles away rather than someone only five doors down the hall but from a different organization. Organizational cohesiveness played a bigger role than geographical distance.”