Guest Post: Controlling your code is the same as controlling anything, your success is in your approach!

Simon SkinnerSimon Skinner has been a Microsoft MVP for 3 years as well as a speaker for several Microsoft shows in Europe, Singapore and the US. Training in most parts of Europe, India and Singapore Simon has proved his skills time over.

Specialties: System Center, Hosted System Center, System Center Application Monitoring, Web Site and .Net services.

Simon started as out as a VBA programmer. After a few years he jumped ship to System Administration working for Companies like GSK, Blackwell and Huntsworth.  Simon turned his focus to hosted solutions based on System Center and IIS web Servers a field which he has remained for the past 7 years and still continues to work in this space. Today Simon is the CTO and Founder for the startup Nubigenus where they have continued to work in the hosted System Center space, creating a multi-tenant solution for System Center Operations Manager.

This post is for anyone to read however if you are a project manager in .Net working with people in different time zones then this may be for you, really I am sharing my findings!

Let’s set the scene with a few bullet points;

  1. You can use any tool to write bad code.
  2. We rarely test our code the same day we wrote it.
  3. We need to understand where the stress points are likely  to be.
  4. Tracking code from its creation is vital.
  5. Tracking code in Production with good controls is less important (I will explain this further later in the last post).
  6. Monitoring Performance is vital to our clients experience.
  7. Control is paramount to the success of our project.

With these 7 simple points we will succeed to create great applications.

The chosen toolsets are;

  1. System Center Operations Manager 2012
  2. Team Foundation Server 2012 SP1
  3. SharePoint Server 2013
  4. Project Server 2013

With the above toolsets I can achieve my goals, share the success and measure the performance of my Project.

Below I have a snippet of code but in a typical project there is going to be 10,000’s even 100,000 or more lines of code like this.


Developers can comment their code as seen below, useful when you find the code however we are going to need a lot more than this.


I can easily add monitoring of my code with APM built inside Operations Manager where I can view issues that would normally be hard to track.

As we can see below I can drill in the code when it creates an exception or performance event with pinpoint accuracy. 


The above is great, however this does not help me project manage my project, so lets look at how we can achieve this.

Below we have a Work Flow, where events are transformed so you can collate them into Agile reporting.

Events are created in our application, APM via the OpsMgr agent displays them in the Operations Manager Console, where with one single click they can be processed into Team Foundation Server (TFS). From here we can process the data further into SharePoint for some cool reporting and dashboards then finally into Project Server where we can see our Work Items and if we made them on time. I am sorry for this out burst but…that’s just awesome, really! When we fix bugs TFS will then tell OpsMgr and close the event in the console.


Now we are getting somewhere, from this one view I can see what work is in Progress, Unfinished as well as the build rate success.


In SharePoint I can also see the progress of the bugs in a high level view, whilst project managing these simple but really informative views helped be no end decide the quality of the code and measure the performance of the developers. 


Still in SharePoint I can see the Project Work Items, Builds and what has been checked in. The key thing to remember is that once set up it’s all automatic and dynamic.


To summarize in the first rather high level view we have taken code processed it in to TFS, where I the project manager can now start to do just that, manage the project. What is my advantage here? I am doing it based on fact, so when we run the code if it generates an event I will get to know about it here, in simple terms (which suites me). In my next instalment we will be going back to the start so we can learn the installation process. These finding are based on a real project which I am happy to share the quality control we put into the project to ensure the results meet the standards we expected.

Comments (0)

Skip to main content