Surprising criticism from parting Microsoft development lead

Jay Bazuzi, once Development Lead for the C# Editor, is leaving Microsoft, and he wrote some surprisingly harsh parting words for his friends before he left; things like “OO isn’t a fad” and that “It’s OK to use someone else’s code”.

Jay starts out:

I have a few thoughts that I’d like to express about Microsoft’s software development before I go.

His post focuses on five topics where he thinks the potential for improvement is large:

• Clearest code wins.
• OO isn’t a fad
• It’s OK to use someone else’s code
• Design your problems away
• Most importantly: we can do better.

Even though Jay was very outspoken, there have not been many comments to his post. Alex Barnett thought it should have been kept internal, but apart from that, the blog post produced much less flame war than expected.

But the sad truth is that Jays arguments is by no means specific to Microsoft. Too many companies would have thought the post was about them and their code base, if they would have seen his descriptions in an anonymized form. For instance, regarding clear code, Jay writes:

Most developers at Microsoft haven’t yet learned the incredible value of writing the clearest code possible. Once I saw a someone make a checkin that added 200 lines in the middle of a 600 line function. I’m thinking it was already about 597 lines too long. Use Extract Method to break them in to bit-sized chunks. Use Extract Class to manage the plethora of methods you suddenly produce. Don’t stop there.

When it comes to the lack of object-oriented thinking, Jay gives an example of how buffer overruns was handled during the last years focus on security. Tools were written to check that a proper length was always passed as a separate argument when manipulating buffers; a solution Jay was not pleased with:

Hey, when you find yourself passing two or more values around together, why not put them in to a class? Just start there. Polymorhism, inheritance, and encapsulation can come later.

Objects can be hard and reusing objects even harder. Microsoft seems to suffer from the good old “Not invented here” syndrome, not only when it comes to external code.

At one point, the Visual Studio code base had about a dozen implementations of a C++ String class, most of them hacked out of MFC. That’s a vast improvement over passing the buffers around, but hey… these library writers are paid to work on these things full time! Why aren’t you using STL or ATL yet?

This isn’t just in C++… in the original implementation of the .Net Framework, there were countless implentations of hash tables. Woah, guys! Let’s get some libraries!

But the biggest take-away for developers around the world is Jay’s discussion on how to continuously improve. Jay describes that he once was the manager of a very inexperienced team; a team that after one year was more productive and wrote code with higher quality than more experienced teams working in familiar code bases. And they did it on schedule every time.

Jay contributes this to the teams ability to continuously improve themselves, and he shows a handful of questions that leads in the right direction; questions that he thinks his former colleagues should ask themselves, but these are actually questions that each and every developer at every company should ask himself or herself much more often:

• “How can I make sure this problem goes away forever?”
• “How can I produce fewer bugs?”
• “How can I make it easier to fix the bugs I have?”
• “How can I make it easier to respond to change quickly?”
• “How can I make it easier to make my software fast enough?”

Truly powerful questions that many or even most teams could benefit from asking themselves periodically.