Changing jobs and learning new roles has taken more of my time than I expected, hence my absence from the world of blogging. But as promised here is the next section in my "Software Engineering - the MS way" posts.


One of the most overlooked thing when it comes to Software Engineering is to establish clear division of labor between the people working on a software project. It is essential for the quality and timeliness of any software development project that right from the start it has been defined who is doing what...and I'm not talking about deciding who programms what components, but rather who designs them, who develops them and who tests them.

So lets look at how development teams within Microsoft divide their labor...

There are three core roles that are defined within a team (more on teams in a later post). These are:

Developers
These are the people responsible for writing the code according to the specifications.

Program Managers
These are the people responsible for writing the specifications and running the projects.

Testers
These are the people responsible for verifying that the developers wrote the code according to the specifications.

There are also numerous support roles:

  • User Assistance
    These people write the documentation, both printed and on-line help. They also create some of the samples.
  • Product Designers
    These are people who make our products look nice - they draw up images, icons, etc. and help us programmers create visually appealing software.
  • Product Managers
    These are marketing people. They are very helpful, since they give us T-SHIRTs and other marketing gizmos. And oh yeah, they also provide generic feedback on what features are important, etc.
  • Usability Engineers
    These are amazing people. They take your wacked up UI and run some tests on it and then tell you how to fix your UI so people can actually use your software.
  • Architects
    These are extremely smart people, very often with grey hair that points out in all directions (think Don Box) most likely caused by high brainwave activity. With these people you talk all the tough architectural decisions and even ask them to help you out on defining complex algorithms.
  • Management
    They do your reviews (salary reviews, not code reviews!!!) and fight upper management for money to keep your project alive.

But lets focus on the core three roles for a moment...

Splitting the development effort up into these three core roles is the key to Microsoft's success in running software projects. By clearly dividing the responsibilities between these three roles, each of them makes sure the other two are doing their jobs and thereby increase the quality of the work being done.

The usual path that is followed within a project is as follows:

  1. Program Manager writes a set of specifications for the project. There is usally one specification per feature or feature group and possibly an overview specification for the project. The program manager (or PM as they are usally referred to) does not write this specification in a vacum. They create the inital draft based on discussion with other PMs and/or product managers. They then send this specification out to the team responsible for developing, testing and writing about this feature (and evt. to product designers and usability engineers if this is a UI feature). Following a set of back and forth informal reviews in Word and through email, the specification is ready for a formal review. In the formal review at least one representative from each of the roles is present. They then critize the specification, the developer has an oppurtunity to raise his concerns about performance, codeability and time constraints. The testers raises concerns about testability and any issues that are unclear in the specification. The User Assitance person asks for clarifications of things so that they can document the feature, etc. Depending on the number of issues raised the PM takes these issues and resolves them either by changing the specification or making decisions to cut features or sub-functionality of features. If there were critical issues raised there is another spec-review, otherwise the specification is considered complete.
  2. The developer takes the specification and starts writing code against it. Sometimes they start playing around with technology or doing prototypes before the specification is actually complete. This way they can provide good feedback about the feature at an early stage. Once the specification is complete the developer writes and debugs code. They do write some smoke-tests that check the core functionality of the feature.
  3. The testers takes the specification and defined test plans and test cases for each part in the feature. It is very important to create automated testing (more on that in another post), so right from the start they start writing those automated tests and add them into the test-suite for the product. This means that every time the developer checks in code, there will be tests available that test this functionality. This is especially important in the latter stages of the development process, when small changes in the code can cause multiple seamingly unrelated things to stop working.
  4. For every bug that the tester finds there is a triage determining whether it should be fixed or not. This triage is done by the PM, a dev and a tester. Bugs are then fixed by the developer and the tester re-tests the code to make sure it got fixed and nothing else broke.

One thing to keep in mind is that you need people with little bit different personalities for being developers vs. testers. Whereas you want your developers to be creative, then you want your testers to be systematic. Testers must have the ability to think up all the various ways in which they can break the code developed by the devs. Developers do not think this way. How many of you haven't tested your own code and then realized when the first normal user touched it that they for example did not enter something into every field on the screen...while we devs were making sure all the data did get saved...we always filled in something...whereas the tester would try leaving fields empty to see how the code handled this.

The PM on the other hand has to have people skills (something often missing in hard core developers :þ). He has to make sure that things are running smoothly. He is the arbitrator when dev and test have conflicts. He is the keeper of the specification and the voice of the customer. He is also ultimately responsible for the success of the project. He also has the fun task of evangelising the product/technology at conferences.

In future posts I'll discuss the software development lifecycle as teams within MS run it and then we will see again and again how these various roles play an important part in getting things done.