Microsoft and mediocrity in programming

A post by Ahmet Alp Balkan on working as a developer at Microsoft has stimulated much discussion. Balkan says he joined Microsoft 8 months ago (or two years ago if you count when he started as an intern) and tells a depressing tale (couched in odd language) of poor programming practice. Specifically:

  • Lack of documentation and communication. “There are certain people, if they got hit by a bus, nobody can pick up their work or code.”
  • Inability to improve the codebase. “Nobody will appreciate you for fixing styling or architectural issues in their core, in fact they may get offended.”
  • Lack of enthusiasm. “Writing better code is not a priority for the most”
  • Lack of productivity. “I spend most of my time trying to figure out how others’ uncommented/undocumented code work, debugging strange things and attending daily meetings.”
  • Lack of contribution to the community. “Everybody loves finding Stack Overflow answers on search results, but nobody contributes those answers.”
  • Lack of awareness of the competition. “No one I met in Windows Azure team heard about Heroku or Rackspace.”
  • Working by the book. “Nobody cares what sort of mess you created. As long as that functionality is ready, it is okay and can always be fixed later.”
  • Clipboard inheritance. “I’ve seen source files copy pasted across projects. As long as it gets shit done (described above) no one cares if you produced unmaintainable code.”
  • Using old tools. “Almost 90% of my colleagues use older versions of Office, Windows, Visual Studio and .NET Framework.”
  • Crippling management hierarchy. “At the end, you are working for your manager’s and their managers’ paychecks.”

There are a couple of points to emphasize. This is one person in one team which is part of a very large corporation, and should not be taken as descriptive of Microsoft programming culture as a whole. Balkan’s team is in “the test org”, he says, and not making product decisions. Further, many commenters observe that they have seen similar at other organisations.

Nevertheless, some of the points chime with other things I have seen. Take this post by Ian Smith, formerly a Microsoft-platform developer, on trying to buy a Surface Pro at Microsoft’s online store. From what he describes, the software behind the store is of dreadful quality. Currently, there is a broken image link on the home page.

image

This is not how you beat the iPad.

Another piece of evidence is in the bundled apps for Windows 8. The more I have reflected on this, the more I feel that supplying poor apps with Windows 8 was one of the worst launch mistakes. Apps like Mail, Calendar and Contacts on the Metro-style side have the look of waterfall development (though I have no inside knowledge of this). They look like what you would get from having a series of meetings about what the apps should do, and handing the specification over to a development team. They just about do the job, but without flair, without the benefit of an iterative cycle of improvements based on real user experience.

When the Mail app was launched, it lacked the ability to see the URL behind a hyperlink before tapping it, making phishing attempts hard to spot. This has since been fixed in an update, but how did that slip through? Details matter.

A lot is known about how to deliver high quality, secure and robust applications. Microsoft itself has contributed excellent insights, in books like Steve McConnell’s Code Complete and Michael Howard’s Writing Secure Code. The Agile movement has shown the importance of iterative development, and strong communication between all project stakeholders. Departing from these principles is almost always a mistake.

The WinRT platform needed a start-up culture. “We’re up against iPad and Android, we have to do something special.” Microsoft can do this; in fact, Windows Phone 7 demonstrated some of that in its refreshing new user interface (though the 2010 launch was botched in other ways).

Another piece of evidence: when I open a Word document from the SkyDrive client and work on it for a while, typing starts to slow down and I have to save the document locally in order to continue. I am not alone in experiencing this bug. Something is broken in the way Office talks to SkyDrive. It has been that way for many months. This is not how you beat Dropbox.

In other words, I do think Microsoft has a problem, though equally I am sure it does not apply everywhere. Look, for example, at Hyper-V and how that team has gone all-out to compete with VMWare and delivered strong releases.

Unfortunately mediocrity, where it is does exist, is a typical side-effect of monopoly profits and complacency. Microsoft (if it ever could) cannot afford for it to continue.

VN:F [1.9.18_1163]
Rate this post
Rating: 10.0/10 (3 votes cast)
Microsoft and mediocrity in programming, 10.0 out of 10 based on 3 ratings

Related posts:

  1. Anders Hejlsberg on functional programming, programming futures
  2. Don Syme on F#, Microsoft’s functional programming language for .NET
  3. Book Reviews: Programming F# and Beginning F#
  4. GPU Programming for .NET: Tidepowerd’s GPU.NET gets some improvements, more needed
  5. Programming language trends: Flash up, AJAX down?

5 comments to Microsoft and mediocrity in programming

  • Notice what Hyper-V is and the rest of your examples isn’t? Enterprise software.

    Windows 8/RT, Surface, and now the Xbox One announcement increasingly make Microsoft look like IBM circa PC jr — a company that tries to sell to consumers, but either cannot or will not build what consumers actually want. Perhaps it’s time for Microsoft to complete the analogy and retreat to the business space where they continue to be popular and profitable.

  • Dan

    I worked for about 2 years in the Windows division and one thing that was a big issue then was to get highly qualified developers. A lot of the smart people are aging and fresh potential is going somewhere else. Unlike other industries, Software is only as good as the people you hire.

  • George M

    As for the intern, “Welcome to the real world buddy”. These criticisms apply to 90%+ of software jobs. Learning to read and understand other peoples undocumented code is a major software dev skill. Guys like him expect everything to be handed to them on a plate. Any documentation often doesn’t help or is out of date anyway. In the real world, developers don’t have an infinite amount of time to spend on spoon feeding the new guy.

  • db

    That is the real world. Documentation is mostly outdated, comments can be misleading or outdated. People tend to modify code but not the comments.
    However, that does not justify it. There should be procedures in place to ‘encourage/force’ proper coding standards including well commenting and documenting. Some kind of peer reviewing or QA reviewing that would eventually point devs into the right direction. But even then, management will come sooner or later to ask “why did this take so long?” even after they sent you email with a big “Bravo” just week before for the good work you did.
    So, at the end, it is all about management making poor decisions to save couple of bucks and missing to realize that they are loosing customers and money in reality. All they care is the number below the line for that quarter, long term benefits to product and team are not considered at all or are used for personal benefit later making a good developer to look for work somewhere else.

  • Clyde Davies

    “Welcome to the real world buddy”. These criticisms apply to 90%+ of software jobs. Learning to read and understand other peoples undocumented code is a major software dev skill. Guys like him expect everything to be handed to them on a plate.”
    It isn’t difficult to write code that’s easy to understand and to comment it properly. It’s called ‘being a good citizen’.