Why I Moved..

Four months back, I made a shift within my company – Moved from a team that worked for Microsoft! A transition of this kind, is generally a shocker for most people! When you’re in the IT industry, working for Microsoft means following strict coding and designing standards, working on pure “engineering” problems and more often than not, getting an opportunity to visit the Hub of it all – Microsoft, Redmond.

Here’s the cliché – That’s All There Is To It!

Companies today survive because of the services they offer. When it comes to an IT company, this one statement broadens to a services offered to a huge spectrum of industries that at some point or the other turn to an IT company for solutions. In effect, an IT company survives because of its ability to get into its customer shoes. It survives because of its ability to win trust and gain customer loyalty.

The reason why Microsoft outsources to a company in India, is probably due to the low cost of man power here. A huge company like that also knows who to play Tough Guy and suck the Best there is from the companies they outsource to. They are strict and extremely demanding because they know that they are a Big Banner to Have! So, tomorrow, if another company offers its services at a lower cost, Microsoft is more than likely to make a move and play it Big there instead!

On the other hand, when you are providing solutions for a Consumer services based company, while it’s true that they turn to an Indian company due to lower costs, what’s more important to realize is that they are more likely to stick around longer due to the trust/loyalty factor that kicks in. They start to recognize and appreciate that we understand their problems and needs and they respect the fact that we are armed to take on their challenges for them! That’s what is most stimulating. That’s what makes sitting in front of the computer most exciting! The fact that you are affecting lives, that you are fostering new relationships, that you are being respected for what you do!

The beauty of the IT industry is that we are at the center of everything that is “Next Gen”. If you are in the right environment, you will be exposed to the best of technologies that can be deployed in the most variety of scenarios. Ten years of working in a tyre company, you will probably know everything there is to know about tyres - how best to maintain them, how often to change them, what kind of chemicals are involved for different road and weather conditions. But ten years in an IT company, with the right team, you will know most of what you need to know about a variety of industries.

Today I’m on a “panel” that works “With Microsoft”! Well, with “Microsoft Technologies”! And we provide solutions for Hospitals, Tyre Manufacturers, Banks, HR ., etc. My knowledge base now can grow beyond just the technical nitty gritties and elevate upto end user experiences and core business problems – That’s where The Real Advantage, The Real Excitement of being in an IT company lies.

The "Centralized - Hub" Leadership Model..

I've recently been kept engaged by an interesting book titled "Microsoft Rebooted" by Robert Slater ..

The book essentially talks about the recovery of Microsoft after the AntiTrust Trial. It is a detailed description of the work culture at Microsoft before the trial, through it and the changes that were identified after. As I was reading the book, I felt elated, over joyed, excited about the work model at MS while it was a startup and at the same time it raised a lot of questions, doubts and apprehensions!

For over twenty years Microsoft had been following the Centralized-Hub leadership model. This essentially meant that Bill Gates served as the Hub that "oozed" out ideas, sugggestions and everyone else would follow. This also meant that everything from product ideas to daily works of the likes of project meetings was regularly attended by Gates. All decisions within the company (that's right, all of them) would have to be approved by Gates. And let me also stress that Gates was always on top of things. He always had significant contributions to make from HR issues to core technical concepts. Everyone in the company knew that if they dropped a mail to him, they would get a response by end of day and that the response would be clear enough to know what should be done next. Gates served as the hub that drove the company and the one place where every key decision took place. Gates liked it that way. Everyone at Microsoft liked it that way! He liked spontaneous plans. He liked taking the leap. He forced his people to perform beyond what they thought they were capable of. At Microsoft, you did not need a promotion to get more work, more responsibilities. For over fifteen years since its establishment, Microsoft was still a start up. Run by one Man - Gates! The Hub! The Source of Everything!

The Hub model took care of a lot of chaos. For a company that was growing in all directions, things were simplified when everyone knew that they were only needed to contact one leader to know if they are on track. No management hierarchy! No slowing down! Quick actions, quicker decisions. Simple!

But the Hub model also raised a lot of questions!
What happens if the leader is missing?? What if people are lost? What if suddenly, there is no direction? What if there is simply too much to handle and the one man show does not cut it! What if things start to slow down instead? What happens if the Hub ever runs out of Fuel!

Thought of The Day!

What if Thomas Edison had not Shared His Discovery of Electircity??

All growth is stimulated by ideas and thoughts that are discussed, accepted and "over analyzed" for alternatives and possibilities...

Google recognizes Best Practices.. I mean it!!

Go ahead.. Type out BP in your Gtalk chat window and Googlt will "blue" it for you..

He he.. Alright, it does not recognize "Best Practices"..

BP is "Sun glasses sticking his tongue out" smiley..

But cool haan?? BP .. :)

OpenXML - The First Look!!

Alright, so what is OpenXML?? Easiest way to find out –
1. Take any word document and create a copy of it in any new location
2. Change the extension of this new copy to .zip
3. Open the file using WinZip and extract to a destination folder

What will you find here?? A set of folders containing a bunch of XML documents! That is what any Office 2007 document, excel sheet or presentation is - a collection of zipped (that’s right, compressed using WinZip) XML files..

With that, let’s try and be intuitive about the possible advantages of something like this:
1. A compressed file is light weight and as such ideal for transporting over the wire
2. Since it only contains XML data which is pure text, limits the possibility of the document being blocked by firewall
3. If all data is structured using XML, it becomes easier to scan and to modify the contents programmatically by simple XML processing
4. In addition, OpenXML, as the name suggests is an open XML based standard and as such comes with the boss of all benefits – Interoperability!

Now, time for some non intuitive advantages:

1. OpenXML is not just a single XML file. It is in fact a collection of XML files. That’s right – Every word document is a collection of XML files! So, even if one part of the file is corrupt, it is still possible to recover meaningful data by replacing the corrupt components
2. The structure allows one to identify if a document contains embedded code or macros, making it easier to filter such documents.
That’s a quick and short intro I know.. But it took me a lot of reading to get here.. ;)
Watch out for a few more updates … Soon :)

Performance Pointers - Basics Revised!

If you ever sit and profile an application, you'll realize that the following operations take up most of your application's runtime:
1. Frequent Object Creation
2. String Operations
3. Method Calls
4. Exception Handling

Here are a few performance pointers:
1. Watch out for frequent object creation. Reuse objects wherever possible
I have seen so many people do this:

public void myMethod()
{
//redundant object creation
List myCollection = new List();
myCollection = this.GetMyData();
}

And this:

public void myMethod()
{
DataRow dr;
MyObject obj = new MyObject();

..Some Database operations..

obj.name = dr[“MyName”].ToString();

//obj.name could be reused in the statement below
Console.WriteLine (“My name is” + dr[“MyName”].ToString());
}

2. Most of the boxing occurs when you are calling .NET FCL methods that provide "object" overloads. Keep an eye on these. Check if there are other options you can use that will help avoid Boxing.
Boxing = Memory Allcoation on Heap + Pointer Creation on Stack + Copying data from Stack to Heap
Boxing is Expensive!!

3. String operations are expensive. Also, since Strings are immutable, every string operation leads to the creation of additional strings. Reevaluate the use of ToString() and Concats in your code. Reuse strings wherever possible.
Consider Ordinal String comparisons over the more commonly used String.Compare().

String.Compare() causes Culture Specific comparisons which involves mapping all characters to appropriate culture specific codes. Ordinal comparisons on the other hand perform basic byte value comparison of strings. This is similar to strcmp in C.

4. Using the right Data Structure can boost performance tremendously. Use keyed collections when you need frequent retrieval of data in random order. Use Hashed collections if you frequently query data. Use Sorted Collections, if you need frequent sorting of large collections.

5. Check your loops for frequent method calls. To avoid it, either inline the method within the loop or tranfer the looping logic to the called method. In addition, avoid accessing static data inside a loop.

6. If you will not be performing any additional work on catching an exception, do not use a try catch block to simply rethrow and exception. Exception propogation and catching is extremely time consuming due to the overhead associated with searching for suitable handlers.

7. Take the overhead of validating variables in order to avoid exceptions.

Threading Performance Pointers

1. Watch out for places where you can use ReaderWriterLock. This class allows multiple readers to access a resource simultaneously. So it definitely serves better than using just a lock which could end up causing contention if you have too many readers. But if your application also has too many writers with long jobs, avoid ReaderWriterLock. While a writer operates, all readers are blocked! If there’s a writer lined up to acquire a resource, all readers are put on hold.

2. Interlocked operations are always best suited for integral increments and decrements. These are very well known to offer the best performance.

3. Avoid using Synchronization attributes for methods that take very long. In such cases, opt for locks at appropriate points to boost application performance

4. Use the Thread.Priority property more often. Most of the times assigning a lower priority to logging modules can help boost up response time for UI applications

5. Most I/O operations can be done asynchronously. Watch out for places where you need to perform File I/O and analyze if you can do it FileStream’s ansynchronous methods – FileStream.BeginRead(), BeginWrite(), EndRead(), EndWrite()

6. Exploit ThreadPools. It’s not that bad to have twenty five threads per CPU for performing independent operations (I/O in particular). Threadpools are also intelligent enough to avoid parallel tasks if the CPU usage is too high. However, remember that we have least control on tasks assigned to threadpools. So use them for asynchronous tasks that most definitely are independent.

7. Threading needs to be done intelligently. Avoid too much resource sharing.

8. Implement threads in places where there is least interdependence. Avoid Suspending threads.

9. Threads are most useful if there are lots of I/O operations to perform and few CPU intensive tasks.

Locking and Synchronization

I’m not a fan of threading! No No Not at all! I do not like it! I hate the associated overhead and to be very honest I haven’t ever dared to get into the depths of it! But I know that there are times you cannot avoid it and when that happens, you realize that the real culprit that has made threading so notorious is thread synchronization/resource sharing!
Nevertheless, I dared myself into exploring threads and the rest and here’s a quick look at on Resource Sharing among threads (very .NET specific) using Locks and Monitors!

Internals

Alright, so to understand this Big guy, get a taste of the internals of synchronizing Ref Types in .NET! I’m gonna put it in a point wise fashion to get on with it real quick!
1. When the CLR initializes, it allocates memory for SyncBlocks on the heap. Each SyncBlock can be associated with just one thread at a time.
2. Every object on the heap has overhead fields associated with it. These are – a pointer to the MethodTable and type descriptors And a SyncBlockIndex. SyncBlockIndex is a 32 bit value corresponding to a SynchBlock.
3. By default the value of the SyncBlockIndex is -1 for every object

What happens when you lock or use a Monitor on an object??

1. Lock/Monitor.Enter() first checks the SyncBlockIndex of the object.
2. If there’s a value associated with it, it checks if the corresponding SyncBlock is owned by the current thread. If so, All’s well. Move onto code execution
3. If the thread for the associated SyncBlock is different from the current thread, th current thread is suspended till the SyncBlock is released by its owning thread!

Great! So the idea is simply to get a reference to the SyncBlock of the object to be locked and to ensure that the current thread owns that SyncBlock!

Locks can be made on objects as well as on types! But locking types is dangerous! When you use lock(typeof(type)), you effectively lock all instances of that “type” throughout your process. So avoid it!
Ideally, Lock(this) is not recommended either! Here’s why –
Assume that you have a class called MyApp. Somewhere in your class, you have used lock(this). In addition some other class has created an instance of MyApp and used a lock on that instance too.

public class MyApp
{
public void MyMethod()
{
//lock this object
Lock(this){
//Do stuff
}
}
}

public class Test
{
MyApp app = new MyApp();
public static void Main()
{
Lock(app){
/*
*a. create a new thread.
*b. provide the object a to that thread
*c. in that thread call, a.MyMethod()
*d. wait for the thread to return
*/
}
}
}

In the above snippet, the object app is locked by our main thread. This object is then being used by another thread to call the method MyMethod which also requires a lock on the object. Obviously, the above code will lead to a deadlock.
Clearly the code is not a good practice. Nevertheless, it was meant to demonstrate that using this could get risky!

Here’s a Solution to the problem

I’m still trying to figure out how it helps. Nevertheless, I can use it as a best practice since I am most definitely clear about the disadvantages of using this and typeof.
So, the solution is to use a private variable of the Object type in your class where ever you need to provide locks.
For example:

public class A
{
private Object thisLock = new Object();
...
lock(thisLock) { ... }
...
}

Like I said, I’m still trying to figure out how this helps. So if the dope above has not already got your head spinning :) please be my guest and help me figure it out!

Here’s a good place to start banging your head:
http://msdn.microsoft.com/msdnmag/issues/03/01/NET/