Parting words for dear friends

  • Article

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

Clearest code wins.

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.

OO isn't a fad

Microsoft has pushed hard over the last ~5 years to make its software secure.  Security is hard, but there's no reason to make it harder.  For example, countless security issues came down to buffer overruns in C++ code where a buffer was passed without a corresponding length.  The response?  Let's write tools that help you find places you pass buffers, and make sure you pass a length along side. 

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. 

(Hey Windows: I'm looking at you!)

It's OK to use someone else's 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!

Design your problems away

Every time you run in to a problem, step back & ask "How can I make sure this never, ever happens again?" 

Got buffer overruns?  Using a buffer class makes them go away.  Having trouble with refcounts? Try CComPtr.  Is your cache getting corrupted?  Remove it, or encapsulate it. 

When we did this in my last C++ project, we found our C++ code started to look remarkably like C#.  That's a clue: C# has already designed away most of the tedium of C++.

Most importantly: we can do better.  

The above complaints are specific, local issues.  In time they can be addressed indivdually, and this blog post will become obsolete.  But there's one thing that Microsoft developers should always be working on: doing their job better.  Ask yourself questions like:

  • "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?"

I once managed a team that did this very well.  They were largely new hires, mostly straight out of college.  But after a year, they were rocking.  They produced features faster, had fewer bugs, fixed bugs faster, and reliably beat the schedule every time.  They far outperformed teams of experienced developers working on familiar code bases, often with well-understood problems.  It was amazing.

EDIT: I wish I could have addressed these issues while I was at Microsoft, but that's hard, and I wasn't successful.  This blog post is about the last chance I have to do anything here; now it's up to you to decide if you can use this.