Author Archives: ssmantha

About ssmantha

A Technologist and Evangelist, with more than 9 years of extensive experience in Microsoft and related Technologies. Working as Technical Solution Architect in To-Increase India since Sep 2006 Role - Technical Solution Architect responsible for creating cutting edge solutions in the Microsoft Dynamics Ax and NAV using .Net framework. Satya enjoys work involving implementation and integration of .NET and related Microsoft Technologies including Microsoft Dynamics AX and NAV, apart from playing around with new software technologies. He successfully built development tools which assists ERP teams to develop better solutions using Agile Practices. Using TFS 2010, Visual Studio 2010 he integrated the Development Processes with the Microsoft Dynamics Ax and NAV. By automating the development processes using the tools and technology, he was able to educate the practices, which in turn is helping people focus more on building innovative products rather than maintaining them. His latest work include a successful integration of ERP on Cloud, a pretty stable integration interface to a third party vendor. Another feather in his cap, automating TFS builds for Dynamics Suite of products on both AX and NAV. He is currently focusing on technologies surrounding ERP on cloud, Mobile Connectivity, XRM 2011 and many more. His areas of interest also include helping Development Teams work in a more structured way using Agile practices. Currently, Satya is working on the a Next-Generation of Business Integration Solutions for Microsoft Dynamics NAV 2013. Using industry proven architecture, he and his team are working on simplifying the domain of integration. Some key work areas he contributed on, Document Processor, Created a Data Model Mapping language and compiler working in tandem with XSLT transformation, and modular Integration Pipeline Architecture design.

Physics of Being Agile

Recently, with all those vibes about SCRUM going around in our organization, a couple of colleagues went for “Certified SCRUM Master” training, incidentally same person trained myself and one other colleague 6 months ago. I got a chance to talk to him over phone and was glad to accept his offer to be a guest speaker in his session. It was difficult to find what to talk, what was expected from me was to share how we are implementing it and our journey with SCRUM. However, understanding the nature of the training environment it was pretty clear for me to send a message to the audience, I just wanted to talk about what can be the real world implementation issues one can have with SCRUM or any other AGILE practise implementation in a place where such concepts are not known.

Jim Collins in his book “Good To Great” started off to explain what is the Physics of going from Good to Great. While trying to understand what he means I started to think Agile as Physics albeit Modern Physics. Why??. Because Classical Physics is governed by Laws, the very nature of Laws is their rigidity. And rigidity is something which is quite alien to Agile. In fact Agile Manifesto itself talks about Principles, which are not that rigid in nature. Try comparing this with Principles in Modern Physics, like the Heisenberg Principle of Uncertainty. Just like how we cannot determine the position and momentum of a particle simultaneously, I see some very similar striking similarities in software.

So what is uncertainty in software, we cannot easily and simultaneously predict the direction of the software and the time when that can be achieved. This very nature of software makes it more an Empirical Approach, rather than a Predictive Approach.

Next came, a statement which is quite close to my heart, this helps me measure the direction in which I am heading. Remember the book “The Goal” I talked about in my previous post. How about little Physics against your Goals? Smile

“Any action which is taking you towards your Goal is productive.“

“Any action which is taking you away from your Goal is counter-productive.“

What is our goal here? Our goal here is to be “Agile” so we measure our actions with the Agile manifesto’s principles, this helps us in understanding the Philosophy of Being Agile.

The last point(s) I talked about was the real challenges we face in our day to day implementation of SCRUM. Initially when I heard that it is not easy I was not believing it. But when we saw that it is hurting us back then I realised the challenges.

As an advocator of Agile practises you might face several of challenges, but I can make out only two :

  • People: It is hard to explain people the philosophy of Being Agile until they see it practically happening.  To make it happen you need like-minded people who should be willing to
    • Experiment, learn and experiment without fear of failing.
    • Fight for the cause, be in regular confrontation mode for the common goal.
    • Sacrifice their mediocrity for a greater good.
  • Organizational: Sometimes it is difficult to implement Agile because the scale in which the organizations want to implement it. That’s if they like it they want to implement it as a big-bang. But that’s not how you can implement Agile practises. These principles needs to be infused, SLOWLY….take small steps and show visible improvements.
      • Sometimes there are financial implications
      • Sometimes there are people waiting for decisions from top management
      • Sometimes there are timing issues, example you are already in between of a release, obviously you wont try your hands on new stuff which can jeopardise your current schedule.
      • Sometimes there are simply lack of proper engineering practises to deal with the shorter iteration philosophy of being agile.
      • and many many more..

I believe somewhere there are solutions, being with thinkers and innovators can definitely help in this case.

Shelving and Unshelving– A source control option with some practical usage.

In TFS version control sub-system, there is a feature for Shelving and Unshelving your pending changes. This is quite a useful operation in source control with a variety of applications. In this blog I will show some scenarios where this operation can be helpful.

Picture yourself in your day-to-day work. And your Boss comes to you when you are really in “The Zone” (I use this term referring to a time-frame when my productivity for the day is the highest, when I am able to code what I think, and more importantly when I don’t like to be disturbed while coding). So  you Boss is at your desk and you have the following conversations:

Scenario :

Boss: “Hey I have got this new feature which I want you to start off immediately.”

You: “Yes, but I am in middle of the feature you already said is most important.” Surprised smile

Boss: “Yes, that’s true, but this new one is more important than the one you are doing.” Sarcastic smile

You: (Thinking I don't know smile) 1

Boss: “Please stop everything, and do what I say.”

You:(Thinking I don't know smile )  2

Boss: “If possible take help of other senior developers too, and try to do it by the end of the day.”

You: (Thinking I don't know smile) 3

You are Thinking Part 1: While you are thinking, your boss has already overruled your current work. He has prioritized your existing work, he also didn’t tell what to do of the work done so far (you are at this point when you are thinking for the first time). You are trying to understand the new work in front of you and trying to find a possible solution.

You are Thinking Part 2: When your Boss says “stop everything”, you are at point 2 thinking what will happen to work done so far. I don’t remember whatever I changed (considering I don’t use any version control). I need to revert back to a state where everything was working fine, and then code the new requirement (More Important than the Most Important).

You are Thinking Part 3: When your Boss says “take help from senior developers”, you are really in mayhem. How would you do that? The senior developer might not have anything related to the new development. How will he do my code review? How will I.. And you are in a endless thought process.

This is what happens when your Boss leaves,

You: @#$@#$#%@#%@#$%@#$%@#$%@#$%@#$%@#$%

Ok, there is a way out if you are using version control in TFS. TFS provides what is called as Shelving (put whatever you changed in a cold box), and Unshelving (take out stuff form cold box and continue). It is just like you hibernate your OS, it remembers all the state you were in and then when you reconnect back all the programs are open.

For more information on shelving, and unshelving read the following link:

Now when you are empowered with this new information, let’s see how your conversation would be:

Updated Scenario :

Boss: “Hey I have got this new feature which I want you to start off immediately.”

You: “Yes, but I am in middle of the feature you already said is most important.” Surprised smile

Boss: “Yes, that’s true, but this new one is more important than the one you are doing.” Sarcastic smile

You: (Thinking I don't know smile) 1 (You have the liberty to think without worrying about How would I questions !!!)

Boss: “Please stop everything, and do what I say.”

You:(Thinking Winking smile ) 2 (You can shelve your changes and get the version which was running just fine before you started to implement this feature.)

Boss: “If possible take help of other senior developers too, and try to do it by the end of the day.”

You: (Thinking Winking smile) 3 (You can shelve the changes for review with your senior developers, who can unshelve and do a code review for you.)

Note: The TFS build system also allows to execute a shelveset merged with the sources present on the server. By doing so you can verify the integrity of the shelveset with respect to your stable version of the source code.

Conclusion: Shelving and Unshelving are really powerful features of the TFS version control system. They save a lot of time from code backup nightmares, working on prototypes, sharing your source code for code-reviews, suspending and resuming code activities. Fortunately, the version control plug-in from To-Increase for Microsoft Dynamics NAV enables the developers to perform Shelving and Unshelving, contact To-Increase for a demo and unleash the power of version control for Microsoft Dynamics NAV.

Change is always inevitable and Changeset makes sense.

Let me start with a question for which I created a small poll. Please select an option to vote and then read further.

If you have not voted for option “You edit single file to resolve the issue/bug.” then you might be facing the pinch for a logical grouping of changes done to fix a bug. Team Foundation Server takes it to the level of logical grouping of changes.

Any piece of functionality we build for a software requires multiple files, until and unless you throw away all the design principles and write code in a single source file. Each and every activity in software development is a change, whether you add some files, delete some or edit some. Everything said above in TFS system needs to be checked-in, so when you see the check-in window it is visible as a pending change, ready to be committed to the source server (Pending Add, Pending Delete, Pending Edit).

Changeset is a logical grouping of the changes you do in source control, it is essentially a collection, what needs to be in the collection is ultimately controlled by the developer. So it is the responsibility of the developer to select the pending changes which would be eventually committed to the source control server.


Notice the Change types “edit”,and “add” in the screenshot above. These changes can now be checked-in as a set which we typically refer to as a “Changeset”. When I said that what contains inside a change set is controlled by developer earlier in this post, I meant that you can select which objects you want to check-in controlled by the checkbox besides every element in the above dialog.

Changeset is a linkable entity, meaning you can associate them as links with work items in TFS. Why is this important? The answer is simple, you never do any change in a software without a purpose when you consider the complete ALM picture. Each work item type, defines a purpose in the software development methodology. This helps us in understanding the purpose of source code changes, as to why we did a particular change, what was the intent behind and some more artefacts (like effort spent, developer comments, to which product functional area it corresponds to, to which release etc., will we dive into these details later in some future posts when we do a deep dive with work items).

Developer Isolation and Team Development

Software development is a team task, meaning there are multiple people are working on a same code-base which collectively results in a piece of software or functionality. What if we share common runtimes and also common code-base? The situation can be quite disastrous if something goes wrong.  In our previous post “The importance of Version Control”, Ron raised some questions in mind of a developer, if we do share a common code-base.

The Visual Studio development environment provides us with a kind of localized runtime specific to a machine.  Developers can now change their code and run on their machine to test and see if their code is working correctly or not. However, this is still not sufficient. In case of team development we require more. We need to share our code-base also. We are talking about “Parallel Development” here.

Parallel development allows multiple individuals to work in isolation, safely developing same, or different parts and versions of a project at the same time. 1

To understand a bit more of Developer Isolation, let’s see how a typical .NET Project works under source control. When you first create a project in .NET it is not source controlled. To do so  you need to add the solution to source control


Once your solution is under source control it is accessible to all the developers. They simply need to connect to the respective Team Project and associate the sources to their what is called a workspace.  There are two types of workspaces, public workspaces and private workspaces. For simplicity we use private workspaces which are mapped to each individuals working folder (folder mapping). Files in this local folder are all marked as read-only so that you don’t accidently edit them. Each file now has two versions, a local version and a server version. The server version is the what we consider as the “Latest stable version”. So when you edit it you are isolated from other developer’s changes since you are working on your local copy of the sources. This is how it looks in Solution Explorer when you have a source controlled solution.

imageNotice the locks besides each version controlled item, it signifies that the file or the source is currently not editable. In order to edit the file you need to do a checkout, right-click on the file you want to edit (let’s say Class1.cs) and click on “Checkout for Edit…”, there would be a small red tick mark besides the file suggesting you can now edit it.

image image

Now once your file is checked-out you can safely edit it and be rest assured that it will not conflict with other developer’s changes who might see that you have locked it. There are some advanced tricks here, like multiple checkouts, but for simplicity we would take them later.

One more important consideration is Isolation of Runtime. Visual Studio by default provides runtime isolation, which enables multiple developers to work on their individual memory space or you can say execution space. So when you build your project your changes are still local and when you run them they are in your local system’s memory space. This level of isolation makes sure that what you changed is reflected in your runtime without adding to confusion with other changes which are not yours and not committed (checked-in , where your version goes to server which is shared and available to all).

In Version Control Systems, it always pays to share what is really common, in the case above you see the sources, what not makes sense is to share runtime which should be obvious by now.

In case of Microsoft Dynamics NAV, we missed it. We noticed multiple developers working on same code base and usually same database and the risks were obvious. Overwriting changes, deletions of objects which seems irrelevant to one developer at first glance etc. Isolation of the development environment was a big challenge for us. Luckily, NAV runtime is quite light-weight so we can bring that into our systems, along with the database. So what’s left, objects (just like sources above). Since these are the real entities we play around during our development. These need to be properly version controlled and tracked. Also we needed to make sure that we every change it is synchronized (i.e. our local database has the code imported and compiled properly).


Something about SCRUM

There are a lot of reference material about SCRUM available online. To start with you can read the following lists:


Succeeding with Agile – Mike Cohn’s Blog

SCRUM Primer

SCRUM is a flavor of  AGILE. To know the philosophy of AGILE please see the Agile manifesto.

In my opinion  SCRUM simply is a way of doing work. People do have a lot of misconceptions when we  talk about SCRUM, they think it is a way to solve the problems. But I see it differently, SCRUM will not solve our day-to-day problems, it will just help them to be visible. What we do with our problems is definitely in our hands.

When both of us started on this project, we incidentally were reading a book “The Goal: A Process of Ongoing Improvement ” by Dr. Eliyahu M Goldratt. This book was a point of inflection for both of us, as we were trying to correlate the idea to find bottlenecks in our development process and to some extent how we manage things at our company. Even after 2 years of development we still correlate the incidents of the book and try to solve them.

“The Goal”, explains the “Bottlenecks” (constraints) in manufacturing process, we stuck an analogy of this with our development process we follow. I would recommend this book for anybody who is serious in implementing agile. It is important to note that it is “Critical Thinking and Constant Actions” which can help a system to improve and deliver better results.

Learning from “The Better Tools”

I have been working on the .NET platform for over 8 years or so now. Prior to that as a student I used to program in a lot of languages (really lot I can count 16 as of now). It goes as long as inception of Microsoft Windows, I wish I could have boasted about life before basic, but during my technology study many years later, I did get a chance to program x86 Microprocessors. It was just like working in museum. You can always relish the feeling but you cannot make good use of it in the more advanced world. Ever thought of running Steam Engines in production in today’s world.

It is difficult of course. Something similar goes with the process, over the period of time we had processes and tools which were just right for programming languages for those days. Building software has always been quite complicated, and with the level of  abstractions growing higher and higher, it has added to more complexity to the system.

I started to feel the need of a better process and a tooling system from one of our old products which we acquired from a company. Unfortunately, things didn’t go well in the process area as the mind-set was not there, and we could not have experimented due to protected IP. However, I was tracking my cheese (Remember Who Moved My Cheese??), Team Foundation Server or TFS in short was there around the block when I first encountered it in its earlier states I guess 2005 or so.  Now with TFS 2010, I could see a better and more mature product, which has the capability of rounding out the complete ALM picture. Also with the advent of TFS 2010, Microsoft also recognized a group of people “The ALM Rangers” round the world who were actively contributing to the process templates and other areas of the product. Reading their documentation is “eye opener” in some cases.

Having said all the above, based on my experience I found TFS to be better suited tool for our needs. Now, was the big challenge, how to incorporate or blend the beauty of the system to help other products which are not native to Visual Studio, that’s the Theme of this blog. Thanks to better extensibility of the system we were able to put our innovative ideas to work for us. The journey is still on and there are miles to go.

In the future posts, we will start with some key areas of mind-set changes with Agile and of course we would also discuss about the TFS tooling we created for Microsoft Dynamics NAV.