Surprising criticism from parting Microsoft development lead

Posted by Niclas Nilsson on Nov 23, 2007

Community

Architecture,

.NET,

Agile

Topics

Programming ,

Object Oriented Design ,

Delivering Quality

Tags

Refactoring ,

Continuous Improvement ,

OOP ,

Criticism ,

Microsoft

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.

1. Back to top

   RE: Surprising criticism...

   Nov 23, 2007 8:29 PM by Casey Watson

   To me, these word don't really seem all that harsh. I think Jay makes some very good points and is in a great position to point out the areas that they have been struggling in.

   Reply

2. Back to top

   Systemic problem

   Nov 26, 2007 10:19 AM by Bruce Rennie

   A friend of mine, who I consider to be one of the best developers I've ever met, often remarks that most (meaning the majority) of developers don't really understand object oriented programming. I think he's right.
   
   I've also often noticed that we (collectively) are often fond of describing what we do as a "craft", usually to avoid being pinned down on things like standard practices, etc. However, few developers I've met actually take the time to work on their craftsmanship as evidenced by the example of one developer adding 200 lines to a 600 line function. No school teaches you not to do that, it's supposed to common sense. Yet I've encountered this kind of thing depressingly often.

   Reply

3. Back to top

   Critisism

   Nov 26, 2007 9:18 PM by Sai Venkatakrishnan

   I suppose whatever points Jay has put seems to a harsh reality in most of the companies. Most of the time the development has become tool driven rather than thought driven. As well with microsoft they seem to more concentrate on hiding their secret recipies than producing good software reusing existing ones.

   Reply

• Older >