If you think about it long enough, you will see that it’s obvious – Saul Gorn

Most of the fresh software engineers and .NET developers may not know what really happens inside the Windows operating system when they implement and run a Windows application. This article explains the Windows Messaging Architecture of the Windows operating system.

Window and Window Class..

The Windows UI application (e) has one main thread (g), one or more windows (a) and one or more child threads (k) [worker threads or UI threads].

An application must specify a window class and register with Windows (d) before it creates a window (a) and displays. A window class is a structure which contains the attributes of a window such as window styles, Icon, Cursor, Background color, menu resource name and window class name etc. Registering a window class associates a window procedure, class styles, and other class attributes with a class name. Each window class has an associated window procedure (c) shared by all windows (a) of the same class in an application. The window procedure processes messages for all windows of that class.

Windows Messaging Architecture Diagram

Window Procedure..

A window procedure (c) is a function that receives and processes all messages sent to the window (a). Every window class (b) has a window procedure (c), and every window (a) created with that class uses that same window procedure to respond to messages. The system sends a message to a window procedure by passing the message data as arguments to the procedure. The window procedure then performs an appropriate action for the message; it checks the message identifier and, while processing the message, uses the information specified by the message parameters.

A window procedure does not usually ignore a message. If it does not process a message, it must send the message back to the system for default processing. The window procedure does this by calling the DefWindowProc function (f), which performs a default action and returns a message result. The default window procedure function, DefWindowProc defines certain fundamental behavior shared by all windows. The default window procedure provides the minimal functionality for a window.

Windows Message..

A Windows message (m) is nothing but a set of parameters such as a window handle, a message identifier and two values called message parameters (WPARAM and LPARAM). The window handle identifies the window for which the message is intended. The message identifier is a constant that identifies the purpose of a message. For example, the message identifier WM_PAINT tells the window procedure that the window’s client area has changed and must be repainted.

There are two types of Windows messages such as System defined messages and Application defined messages. The system sends or posts a system-defined message when it communicates with an application. An application can also send or post system-defined messages. For example, the WM_PAINT message identifier is used in system defined message which requests that a window paint its contents.

An application can create messages to be used by its own windows or to communicate with windows in other processes. If an application creates its own messages, the window procedure that receives them must interpret the messages and provide appropriate processing.

Message Queues..

The Windows operating system uses two methods to route messages to a window procedure : posting messages to a first-in, first-out queue called a message queue (l), a system-defined memory (q) object that temporarily stores messages, and sending messages directly to a window procedure.

The Windows operating system maintains only one System wide message queue (l) for the all applications. And, another message queue (j) is created for each graphical user interface (UI) thread. Whenever a user creates an UI thread, the message queue is also created for the UI thread.

Message Flow..

DOS based applications make C-Runtime function calls to obtain input from the system. For example, it calls gets() C-Runtime function to get input from the keyboard. But, Windows based applications do not make explicit function calls to obtain input. Instead, they wait for the system to pass input to them. This is why Windows-based applications are event-driven.

Whenever the user moves the mouse, clicks [1] the mouse buttons or types on the keyboard, the device driver (p) for the mouse or keyboard handovers [2] the details to User32.dll (n), which in turn converts the input into Windows messages and places[3] them in the system message queue (l).

The Windows operating system removes the messages, one at a time, from the system message queue, examines them to determine the destination window, and then posts [4] them to the message queue of the thread that created the destination window. A thread’s message queue receives all mouse and keyboard messages for the windows created by the thread. The thread removes [5] messages from its queue and directs the system to send [6 & 7] them to the appropriate window procedure for processing. How does a thread remove a message from thread’s message queue and process? Let’s discuss now.

Message Loop (or) Message Pump..

A Windows application has a WinMain() function which is the entry point for that application, like main()function in ‘C‘ language program. The WinMain()function acts as application’s main thread function. The following three lines of code in the WinMain() function is referred as Message Loop or Message pump.

while (GetMessage(&Msg, NULL, 0, 0))
{
    TranslateMessage(&Msg);
    DispatchMessage(&Msg);
}

The message loop’s GetMessage() call checks the message queue for windows messages. If it finds a valid message, it removes a message from its queue. After removing a message from its queue, an application can use the DispatchMessage() function to direct the system to send the message to a window procedure for processing. If there are no messages in the message queue, the GetMessage() call will be blocked till a valid message comes to the message queue.

In between these two calls, the TranslateMessage() method call does nothing, but simply translating virtual key messages into character messages. Your application still works, if you comment this line. Only thing is, your test team will file 50 keyboard related bugs.

Journey Ends Here..

The message loop (while loop) breaks when the GetMessage() retrieves a WM_QUIT message from the message queue and subsequently application’s main thread quits. That’s all, the application’s life comes to an end.

Finally..

Now, enjoy .NET application programming by knowing the messaging internals. This article is an another flavor of MSDN article about ‘Messages and Message Queues’.

I wrote and published this article in Aditi’s Mindscape magazine in 2008. Even now, it may be useful to many developers who don’t know the internals of Windows messaging architecture.

-Xavier Robinston Antony Tuesday, 24 August, 2010

Xavier Robinston Antony Windows

Elegance in programming is not optional - Richard A O’Keefe

When I craft software, naming classes and variables is one of the toughest task. I spend considerable amount of time for naming a solution, projects, classes and variables. I strongly believe that a good naming convention makes the code more elegant, organized, readable and maintainable. Usually, my code review process results more naming comments

After I started coding in C#, I was never satisfied whenever I handled bit flagged enum types, not in terms of writing the core bitwise logic, but the naming and structuring the code. Of course, I was pretty much comfortable coding the same in C++. I found a clean approach to handle bit flagged enum types. Have a look.

How to use..

try
{
    FileEx file = new FileEx();

    // Add three attributes to the file
    file.Attributes += Attribute.ReadOnly;
    file.Attributes += Attribute.Archive;
    file.Attributes += Attribute.Compressed;

    // Check whether or not the file is ReadOnly
    if (file.Attributes.Contains(Attribute.ReadOnly))
    {
        Debug.WriteLine("Yes.. File is ReadOnly");
    }

    // Check whether or not the file is ReadOnly and Compressed
    if (file.Attributes.Contains(Attribute.ReadOnly) &&
        file.Attributes.Contains(Attribute.Compressed))
    {
        Debug.WriteLine("Yes.. Files is ReadOnly and Compressed");
    }

    // Remove ReadOnly attribute
    file.Attributes -= Attribute.ReadOnly;

    // Check whether or not the file is ReadOnly
    if (!file.Attributes.Contains(Attribute.ReadOnly))
    {
        Debug.WriteLine("Oops.. Looks like some made this File writable");
    }

    // Remove ReadOnly attribute
    file.Attributes += Attribute.ReadOnly;

    // (or) we can use the FileEx property 
    if (file.IsReadOnly)
    {
        Debug.WriteLine("Yes.. File is read only now");
    }
}
catch (Exception)
{
    // Do something for handling exceptions
}

Here is the code..

/// <summary>
/// ‘Attribute’ enum type holds various types file attributes
/// </summary>

public enum Attribute
{
    None = 0×00       /* 00000000 */,
    ReadOnly = 0×01   /* 00000001 */,
    Hidden = 0×02     /* 00000010 */,
    System = 0×04     /* 00000100 */,
    Archive = 0×08    /* 00001000 */,
    Compressed = 0×10 /* 00010000 */,
    Encrypted = 0×20  /* 00100000 */,
    Directory = 0×40  /* 01000000 */,
    Device = 0×80     /* 10000000 */,
}

/// <summary>
/// ‘Attributes’ is wrapper class to manipulate bitwise enum operations
/// </summary>

public class Attributes
{
    private Attribute _items;

    private Attribute Items
    {
        get { return _items; }
        set { _items = value; }
    }

    public Attributes()
    {
        this.Items = Attribute.None;
    }

    public Attributes(Attribute attribute)
    {
        this.Items = attribute;
    }

    public bool Contains(Attribute attribute)
    {
        return (((int)(this.Items & attribute)) != 0);
    }

    public static Attributes operator +(Attributes source, Attribute attribute)
    {
        return new Attributes(source.Items | attribute);
    }

    public static Attributes operator -(Attributes source, Attribute attribute)
    {
        return new Attributes(source.Items & ~attribute);
    }
}

/// <summary>
/// A FileEx class to demonstrate how to use ‘Attributes’
/// </summary>

public class FileEx
{
    public Attributes Attributes { get; set; }
    public FileEx()
    {
        this.Attributes = new Attributes();
    }

    public bool IsReadOnly
    {
        get { return this.Attributes.Contains(Attribute.ReadOnly); }
    }
}

Compiler : VS2008 on .NET 3.5

Finally..

Sometime back, I used bit flagged enum types in WCF. I was facing an issue due to improperly handled flagged enum type which swallowed tons of my time.. So be aware and careful.

The following two things make me more happy in this code

• A Singularized name for ‘Attribute’ enum type
• A Pluralized name for ‘Attributes’ wrapper class

I really enjoyed writing this code. I am pretty sure, a developer who loves code simply loves this code too. Extend this code as you like..

Exercises..

1. Try investigate how, when and where to use bitwise shift operators.

2. Add a ‘[Flag]’ attribute to ‘Attribute’ enum type as shown below and debug through the code. What is the benefit of using ‘[Flag]’ attribute?

[Flags]

public enum Attribute

3. How to write the following code without type cast?

(((int)(this.Items & flag)) != 0)

-Xavier Robinston Antony Sunday, 22 August, 2010

Xavier Robinston Antony C#

Disclaimer: Since it’s relatively new concept to digest, I’m gonna go slow and might repeat!

Well, if you were a computer science student like me, I’m sure you would have your own taste for Robots from the college/university you graduated to build world’s greatest(!) robot. I’ve tried hands-on to create few basic robots, sleep with those Fuzzy logic books as pillows, travel from library to library for more books on robotics, Butter up dad for the extra pocket money to buy robotics toolkits, quarrel with your friend in mid-night when everything breaks up and miraculously rebuild everything in shape at about 4 AM in the morning before the demo of the project that day well this was about a decade back… Everything around robotics world was little primitive but things have evolved now!

One such evolution is Microsoft Robotics Studio. More info at http://www.microsoft.com/robotics

The robotics studio helps you to create and control industrial robots or pretty much any kind of robot. Well, surprisingly looks like I still have the some quest  that i had 10 years back and in the process of building a new robot using this. I will write a little more on this shortly.

But before that i would write about getting basics correct and some new thoughts as i started learning this framework in this multi-part article.

The objective of this article is to put new ideas/concept in your mind, to make you think about a fresh/new approach for building High Performance Computing & Distributed Software Solutions using Robotics.

Wait a minute… Robotics && (HPC + Distributed Computing) ? Do they really coerce? Don’t they sound two different opposite poles? Well, the truth is the Robotics World has evolved silently in parallel to the commercial software industry and has numerous technical inventions which are not being used in the main-stream commercial software computing.  

The objective of this article is focused on something interesting, which is already creating ripples around the industry through its 2 new technological inventions - Concurrency and Coordination Runtime (CCR) and Decentralized Software Services (DSS).

Well, to begin with CCR was initially built for robots because robots are expected to respond for *Millions* of concurrent behaviors like touch, sound, color detection, visibility, motion sensors et al and CCR was built to cater these needs. But, once this framework was built, the inventors realized the real potential of this framework. That is, the CCR also addresses the need of mainstream software especially the High Performance computing needed by modern day web software’s, distributed systems and service-oriented applications to manage asynchronous operations, deal with concurrency, exploit parallel hardware and deal with partial failure. CCR is complemented with Decentralized Software Services (DSS) a lightweight .NET-based runtime environment that sits on top of the Concurrency and Coordination Runtime.

Decentralized Software Services (DSS) provides a lightweight, state-oriented service model that combines the notion of representational state transfer with a system-level approach for building high-performance, scalable applications.

Well, for those of you who do not like the definitions – here is the quick synopsis

CCR = Programming model for Multi-threading + inter-task synchronization i.e. think about some one magically removing those complex multi thread management code from your programs yet it runs perfectly multi-threaded! i.e. think about multi-threading without mutex, semaphores, deadlocks… does this ring the bell somewhere? read on..

DSS = Framework that allows to run your Services anywhere on the network.

Alright, by now if you would have questioned HOW? the answer is that we will be doing threading without Windows threading model. A Brand new threading infrastructure that enables multiple tasks to execute concurrently on a single computer.

And… how about executing these multiple tasks on completely separate computers and manage it centrally?

In short with CCR + DSS we will see linear scaling on high-volume data and high-transactional software’s in industries like Medicine, financial trading, scientific modeling, messaging systems or even increased scaling and concurrency on the enterprise search servers. This is possible because CCR manages asynchronous operations, exploit parallel hardware, deal concurrency and handle partial failure.

Figure 1: CCR Architecture

Now… Let’s get bit technical…

In Figure 1 I’ve tried to depict the architecture of CCR as I understand. The Dispatcher depicted in the end is the real critical piece which provides stunning scalability & maximizes concurrency in the application, rest of them are the object model that support the Dispatcher.

To begin with, the Portset is a FIFO queue of a Port. Port can be any valid CLR Type. The receiver manages it’s own queue and is code guarded by an “Arbiter”. The Arbiter is more like a gate keeper which actually filters the message and executing appropriate messages.

The dispatcher queue is the real load-balancer and scheduler of tasks, they also manage the data, execution and resources of these tasks.

The Boss of everything here is Dispatcher. The CLR Thread pool is a single and process wide execution resource. But, CCR allows *multiple* completely isolated pools of OS threads and completely *abstract* the complications of thread management from the programmer. i.e. you don’t have to worry about deadlocks, mutex et al anymore. 

also, CCR allows to share a single dispatcher between hundreds of software components from heterogeneous networks, which can *load balance* thousands of tasks using a very handful number of threads.

Let’s explore DSS in-depth and a real time code example in Part 2 and Part 3

Logu Krishnan Robotics

How can an unplanned work have pros?
Well, in one of my recent project, I faced a situation where I had to decide if I can accommodate an unplanned work. This unplanned work got stimulated due to technical reasons as the senior tech member of the team pointed out to a code base that needed refactoring. To find out more, read through this blog and do put forth your comments and thoughts…

Have you managed a long running product development project in a co-engineering mode where the team is highly experienced enough to understand what is good for product? Yes, you read it right ‘product’ and not project. Very recently, while I was handling such a project, we had a release that required code refactoring as one of the unplanned task. I had a small debate with this high caliber tech person. The whole explanation ended with one strong sentence. He said, ‘You can never convince the business owners to have a feature with 50-75 story points for code refactoring work.’ For a moment, I thought, ‘this is true’ and checked with him multiple times if this had any impact on the schedule. This highly dedicated tech person was not going to budge, he openly challenged that before the beginning of QA phase, he would complete the refactoring work.

From my experience, I know: “The business owner wants new features to be developed and they only look for value for money. The time to market new features is so important that, they would never agree for such change request.” However, I decided to discuss this with my SPOC (single point of contact). I knew my SPOC to be a highly technical person who understood this product/domain very well. We did not succeed in convincing for this refactoring work, but all my SPOC said was if you think there will be no impact on schedule, you are the PM and you decide ‘what is best for the project’. I knew he was also under pressure to meet the timelines. After hearing this response, we came back and thought to drop this work. But this techie was adamant and said come what may, he will work on this. This left us with no choice but to accommodate code refactoring work. We decided to leave everything on this techie who would ensure to take things to closure.

Are you thinking Agile?
With technology enhancement and experience, people become more knowledgeable and do hit a code section that requires code refactoring? Should we take up such unplanned task? As a general project management philosophy, I would not have encouraged any unplanned work. But in this case I felt why not? These are small value-add that will take the project/account to new heights. Shouldn’t we think product, why should we always limit ourselves with frozen requirement, why can’t we be agile? Will this gold plating bring success; all such queries were bothering me?

Team Dynamics and Assumptions…
The team size of 30 members including devs and QA at the ratio of 2:1 was working on this project. The functional manager and 2 other devs were working from Onsite(US). The spec was frozen and we had pretty aggressive estimates. On top of this, like any other project, there were unknowns, assumptions, impediments and risks to be looked into. So we started working on new feature development and all our prime focus was on this. Meanwhile this techie was refactoring the code base. The number of new features that were being developed was good enough for QA to focus on this testing. There were few assumptions from the code refactoring work that if we test all the new features thoroughly, we would have covered all areas of the product.

Go, No-go decision?
The dooms day arrived and it was time to go live. We had shared the list of known issues and discussed each one of these before we decided to go-live. Production Servers were down over the week-end and we had smooth deployment. It was time for the business owners to sign-off when the biggest shocker mail was sitting in our inbox, next morning. There were few changes in the core product which is bread and butter for them.

A look into Production bugs…
These changes/bugs may sound simple and one may tag them as P2/P3 issues, but this would have had major impact on all their customers. They were:

1. The order of information published in the core product got changed
2. The number of results were different (Later we found the previous version had bugs and this was actually fixed now)
3. There were missing links which use to direct the user to the web version
4. Location missed displaying the city name. It just displayed State names.

The entire product team and the business owners were pissed off and we got our morning dose from both Client and management. And the techie working on this claimed this as actual requirement and pointed towards some unassigned product backlog items and discussions. These were never prioritized and were lying in backburner.

What went wrong?

1. Lack of Test Strategy: Assumption that testing all the new features will ensure stability of their core product went wrong.
2. Communication Failure:
   1. During code refactoring work, the changes in functionality was taken up. This was not discussed with PGM (Program/Functional Manager), PM or the test team.
   2. Leaving all aspect of code refactoring changes on single person and not extracting information was another failure.
3. Code walk through of Architects or senior techies in the team was missed

Root cause analysis…
You must be thinking this blogger has gone nuts. Even after knowing such high client impacting bugs were introduced; how can there be a pro to it? If you notice the root cause for this problem, it is not pointing to delay rather it is pointing towards unplanned testing strategy, communication failure. Knowing that this code base is related to their main product; we should have strategized dedicated testing. If these bugs were caught 2 weeks prior to go-live date; we would have fixed this. A code walk-through of technical architect, peer code review would have helped.

What was missed in the process was communication with key stakeholders such Test Manager, Functional Manager, Project Manager. This led to gaps and late finding of unforeseen bugs during the Go-live phase. One week later a patch was released to address these issues. An excellent product with all new features integrated went live. All the hard work and effort to build the new features went in drain and I felt sad for the team that they did not get the appreciation for the amount of features they had built in such a short span. This was a big learning. Yes, what could have been a major successful release became a disaster.

Dos and Don’ts…

1. Do not believe in assumptions – isn’t that simple?
2. Track your assumptions and have one round of check to ensure these assumptions are right.
3. Note down your additional communication channels and have a plan to communicate.
4. Knowing client’s business and their core product, the team including this techie should have touched base regularly.
5. Irrespective of who is coding, have walk-through of code. Peer review would help.

Simple, isn’t it? What a hard way to learn this!

How to get a buy-in for such unplanned work from business owners?
Ideal situation in such scenario is to build a strong case study around this and show dollar value or revenue loss due to bug fixes, patchy code base. This will help business owners understand the need of code refactoring. May be QA team needed an additional 1 week of testing effort. Such black holes will exist in the code base and tech team along with PM & PGM should build a strong case to get buy-in from business owners. Yes, PGM’s must also be included as they are usually based out in Client’s location and can convince better. If we can show the value loss in terms of revenue or effort; it will be understood and prioritized. Even if first attempt fails, try again and wrap your learning’s and present it in such as way that everyone atleast understand this. It would definitely be ideal to work on a task that is planned.

So, share your thoughts/comments….Did you find this article interesting? Do you agree with me? Do you disagree with me? What else could have been done proactively to ensure success?

Shrinath Inamdar Life at Aditi, Project Management

What is a Metric?

Effective management of any process requires quantification, measurement and modeling. Software metrics provide a quantitative basis for the development and validation of models of the software development process.

Why Metric..?

These metrics can be used to improve software productivity, quality and overall process improvements by means of appropriate and timely preventive and corrective measures. These are essential as it provides quantifiable justification of facts and accordingly helps us re-align towards the goal.

What are the metrics that are essential for Software development?

Following are few metrics that must be applied to get useful information:

1. Management:
   1. Schedule v/s Effort Variance
   2. Budget v/s Revenue
   3. Profitability
2. Team Members (Developers and Testers)
   1. Time spent per task per person
   2. Time spent on rework (COPQ -> Cost of Poor Quality)
   3. Study of Impact Analysis wrt changes and defects
   4. Test cases planned, executed and its result
   5. Code Review Effectiveness
   6. Defects/KLOC
   7. Defect Removal Effectiveness
   8. Test Coverage

If you notice most of these metric is related to time taken for a task, code review and rework time. Very often timesheet is the most neglected area wrt process or this is the one that takes the beating when it comes to timely quality delivery.

Let’s discuss few important metric that are useful:

1. Cost of poor quality (COPQ)
   

   This is one of the metric that must be given very high importance. COPQ comprises of undesired costs which are generated as byproducts of defective and inconsistent processes.

   If one converts these numbers into dollars, it will give true information on ‘how much effort went into fixing issues’ OR ‘how much revenue was lost due to bad coding’. Having said that ideal scenario will be to have zero COPQ, but truth is every software has bugs associated with it. Most of these software products go live with known issues or bugs. These are prioritized and released as patch releases.

   Overall goal should be to reduce rework as much as possible and apply certain processes such as:

   1. Following coding standards and its checklist
   2. Logging and tracking code review bugs against the developer and using this as a measure to provide timely feedback. This way it helps individual to raise their own quality bar and reduce the number of rework
   3. Every check-in must follow coding standards, checklist. It must be peer reviewed by Senior tech force in the team
   4. Updating these standards and checklist on regular basis depending upon the new learning’s.

    

   Lot of free tools is available to ensure best coding practices are followed, such as FxCop, StyleCop, NUnit etc. Also note the cost of these poor quality decreases if you catch these early in the cycle. This metric is closely tied with code review effectiveness as well.

    

2. Code Review effectiveness (55% to 60%)
   

   As mentioned in previous section, the goal should be to catch the bugs early in the cycle. Ideally lot of these bugs must be caught while conducting code review. The industry standard wrt code review effectiveness is 55% to 60%. This means that one must catch 55% to 60% of bugs during code review itself. This means only 40% to 45% of bugs can leak through and these may be related to functionality issues, user workflow issues.

    

3. Defect Removal Effectiveness (DRE around 98%)
   

   Once the QA team certifies that the software product is ready to go live. The number of defects that can be found during UAT(User Acceptance) must be just around 2%. Let’s say during QA phase the number of bugs that QA team found for a particular software product was 400, then the number of UAT bugs can be at the max 2% of 400 which is 8.

    

   Aim should be to ensure that 98% quality is achieved along with list of few agreed upon known issues. One must keep this as benchmark and improve further.

    

4. Key Management metrics
   
   1. Effort Variance (10 to 12% max)
   2. Schedule Variance (0 to 5% max)

    

   These metric benchmarks are different in different companies. Most widely used metric range for the effort variance is 10% to 12% max. In case this is exceeding, it means Scope Management has issues and needs to be fixed. It all boils down to expectation management and applying proper estimation process. Learnings from previous retrospection must be applied to ensure success and continual improvements.

   Schedule variance, ideally should be aimed as 0% variance; which means delivering quality product on time (on the agreed upon date). These dates are initially agreed upon depending upon the scope of work, number of resources and the time it takes to build the scope, test, integrate and deploy.

    

   The list of these metric is huge. But one thing at the end finally matters is “Were you predictable wrt quality and time“. If yes, you have met the project objectives.

    

Some sample metric are shown below:

 

Case Study Project: ABC Project

Problem Statement: To build a customer portal that integrates with defect tracking database, provides content management, helps provide licenses info, download and upload relevant licensed Software and its patches.

Project Challenges: Initial 1-2 weeks of RA phase was getting dragged till 4-5 weeks. The key stakeholders had confusion on the requirements, wireframes and were debating what the best use case wrt be usability. They felt its better to be absolutely clear before development phase begins. The onsite PGM was fairly new wrt MOSS technology and had to commit to client on ‘what is possible out of the box and which requirement requires customization’. In such a situation what was committed at the end. This project was a fixed price project to be delivered within 3 months duration and with fairly new MOSS developers. Dev’s would have sat idle if we had waited for requirement to be frozen. How did we resolve these challenges and much more…to know this read further? J

First proactive action: Development was initiated much before the FS was frozen. The assumption was that 30% of the requirement may change. This means certain nitty-gritty would come up and we had to apply these changes. Technical design sessions and approach was discussed and documented. This laid the solid foundation for the team to get started in the right direction.

Second proactive action: Since requirement had evolved while development was in progress and to ensure there is uniform understanding among all the key Stakeholders, we planned 3 demos before the final release. This helped us to re-align and set right customer expectation. Early demos of the product helped these key stakeholders to decide upon what exactly they wanted. The changes wrt user workflows, changes in feature, UI changes helped this project raised a CR that was almost 30% of its initial value. Multiple benefits…isn’t it?!! J

Other critical challenges: Since development was scattered and requirement were not getting frozen, the check-ins were done in working folders. The code review happened only after 1 month’s time. This was the time when we first reviewed the code and realized that the team was way behind the coding standards. The data below speaks for itself. Check the defect numbers 35, 27, 32 and 17…

Corrective Action: Detailed code review feedback was given to individual developers. Based on this a code review checklist was prepared, coding standards were re-circulated and we walked through these standards and checklist for 3-4 hours. The checklist was updated as and when area of improvement was required by the team members. FxCop was implemented, defects/KLOC was published with individual developers and expectation was set.

What was the improvement?

Applying these simple rules such as following coding standards, checklist and peer reviews helped the team achieve better quality. Check the new defect numbers: 6, 8, 8 and 7 as against initial defects 35, 27, 32 and 17.

Well, you are right, team had to stretch and go extra mile to ensure quality standards which the MOSS Solution Architect was expecting were met. Check out the Effort variance thereafter:

Achievements: This project was delivered on time with required quality and by the end of this project; we had quality developers who were MOSS experts as well. This dev team is grown into Senior Developers and they cherish the learning’s of the project even today.

Shrinath Inamdar Project Management

SaaS (Software as a Service) – refers to a model where a software provider provides an application to customer for use as a service, whenever wanted. Subscription to the service includes licensing, subscription, etc.

Since the application is developed, hosted and maintained by the provider, the customer does not bear the direct cost of hosting and maintenance. Also, since the service is available over the internet, it makes it easy for access from different locations. The deployment and time to profit is also reduced for smaller companies.

SaaS is a good option for small, non-complex companies. These processes allow these small companies or startups to focus on the more complex business and personal processes rather than the routine.

However, there are a number of cases where this model would not work either for the provider or the customer.

Data speeds: The data transfer happens over the internet and not over the ethernet speeds that most people are used to. This is not helpful for cases where you need to use the service frequently and for time critical processes.

Data security: This is a specific concern for all customers since it is their data (and potentially thousands of their customers’ data) that is present at the servers of some third-party. In addition, the data transfer happens over the internet. There are significant gains being made in this area, however, with the advances in technology, the risk still remains high.

Stability: The provider might go bust. What should a customer do if their service provider closes shop? How does he go about retrieving his data? What should a provider do when a customer goes missing? This impacts his revenue stream.

Customization: This is not recommended for applications or services that require a high degree of customization. This is true in cases of applications such as manufacturing, business intelligence or ERP, any applications that are at the code of a company’s business practices and provide the differentiation from the market. If a customer needs to pay for the customization, he might as well get a traditional enterprise application build for himself. If the provider pays for this, it might not turn out to be cost effective for him.

Integration: If my software needs to integrate with other software, SaaS proves to be a difficult model to work with. Since parts of my solutions are not with me, the customer cannot change or ask for changes easily. Since the product (under the SaaS model) is a complex one being used by multiple customers; the provider cannot change it easily either.

Active (in-process) applications: SaaS works well when a user needs to make a few disconnected calls to the service to send or receive data. If he needs the application to be online (where a long connection is needed to make continuous data entry), the remote nature of the service and the data access over the internet makes this model prohibitive.

So where does this leave us now?

I believe the answer lies somewhere in the future – Cloud Computing and thin clients.

Cloud computing in general provides a useful computing power over the internet. Could computing generally encapsulate these three items– infrastructure as a service, platform as a service and software as a service. It is the first two parts that will help solve the issues with the third part.

Thin clients are gaining more traction, especially in the mobile world, as the future of application or software development. The idea is to have a thin client that knows how to connect to the server and display the data or results. This relies more on the use of services (custom enterprise applications or third-party services) over the internet.

Some of the earlier mentioned issues might still be around with the new development and delivery models, but with the increase in the power of the internet and the computer itself, we will soon look at a different list of pros and cons.

Ravi Yadavalli Architecture & Design

Historical move by both Apple and Microsoft to work together ripples the Online Mobile Search market. Google enjoyed the default search status so far with Safari browser. As the Google’s focus in Mobile is changed dramatically and came up with its own OS and mobile devices, it is fast becoming a serious competitor for iPhone core business. Microsoft actively looking for all possible opportunities to win some ground in Mobile world trying to grab this and initiated discussions with Apple to make Bing as the default mobile search engine.

What this simply means is Microsoft Bing becomes the market leader in Mobile search. Stats say that Google enjoys 86% of mobile search whereas Bing is mere 11%. The key here is major chunk of Google search requests coming from iPhone. Microsoft already has Bing search iPhone app which has more futuristic search options such as location based with voice commands etc. On the other side, Google betting big on its Android platform and Google’s history clearly says the way they emerged as number one web search engine after disassociating their search engine with Yahoo. History repeats in Mobile?

Sreenivasa Rao Pilla Life at Aditi

Project Management – Planning is Agile 

Software estimating and planning is all about determining an appropriate schedule or deadline. Planning happens in the initial phase of the project life cycle and once committed to a schedule and stated quality, one is bound to meet the agreed accepted criteria. ‘Not really’; it’s not just that, isn’t it? So, what is planning? Can we state that “Planning is agile” and happens through-out project life cycle? Let’s find out various issues of planning and how we can ensure proper planning.

Planning is one such process group that is an ongoing activity. Planning plays an important role in various knowledge areas such as Scope planning, Human Resource planning, Cost planning, Quality planning, Communication planning, Risk Management planning, Risk Response planning.

The plan must be revisited whenever there is any changes or impact to any of the above mentioned knowledge areas. Other important areas when a plan must be revisited are:

• Change requests and Accepted changes
• Missed Scenarios being identified
• Requirements getting elaborated progressively
• Change in either dependencies, assumptions, risks or mitigation plan

Lets dive deeper:
Planning process involves finding an optimal solution to the overall product development. In the initial phases of the project, we may feel x number of features can be developed in y months and we can deliver the product on a certain date say 15^th Dec 2009. But as per Barry Boehm’s cone of uncertainty: in the initial product definition phase, a project schedule estimate is typically as far off as 60% to 160%. After the requirements are clearly written; the estimate might be still be off by +/- 15%.  Knowing this, we still make commitments such as the product will be released on a certain date. But this does not mean we do not commit on dates. Variance within accecatable range of +/- 10% is good; provided such impacts are known well-in-advance and informed. Often we miss informing this variance factor in advance to all necessary key stakeholders and hence creating unhappy clients.  

Let’s understand why it is important to inform all relevant stakeholders.
Clients would have committed to their customers based on our commitment on release date. They would have planned user trainings, preparing marketing campaigns, arranging necessary logistics for go-live etc. Any changes to the release dates without prior notice will impact their plans and thus creating unhappiness and dissatisfaction. As PMs we are responsible to set right expectation.

A good planning process supports this by:

• Reducing risks or uncertainty
• Supporting better decision making
• Establishing trust and conveying right information

 As PMs , some mistakes that we make, or at least I have made are:

• Activity based planning…
  We go by activity based planning and thereby losing the focus on feature priority
  • Once we are into activity based planning, we go by what is good logical flow w.r.t. development and ignore feature priority. This way we can easily lose focus.
  • If an activity was planned for 4 days and subsequently developer finishes it in 2 days. We take the stick and usually penalize the developer for giving padded estimates. Worst, we start assuming that the developer would complete tasks earlier than planned
• Assumptions, Risks or Uncertainties…
  Ignorance to assumptions, risks and dependencies often brings in late surprises that are not initially envisaged, and thus not estimated. This results in schedule slippage and in turn may call for dropping an important feature to meet the scheduled date.
• Multitasking…
  We often expect our team to multi-task. While planning this, the resource usage goes quite close to 1.5 or 2 times. This is one of the planning activities that is often ignored. Multi-tasking means context switching and productivity loss of team members. There are occasions when one can be highly productive when multi-taking. For example: Execution of a back-end job to load 1 year of data in parallel with other development activities. Care needs to be taken to identify if multi-tasking is possible
• Gold Plating…
  We all want to impress our clients and sometime choose to overdo by taking up stretch goal features or refactoring work into scope. When deep into design and development phase, we often hit roadblocks and identify areas that require refactoring. This can easily drift our initial vision and result in main feature being ignored. Instead of creating such tasks as in-scope features and we often tend to please our clients.  This type of work where one tries to please the client is called as gold plating.
• Setting Expectation & Prioritization…
  Between gold plating and business priority features, we often lack convincing the business owners on non-functional work. Such refactoring work which is technical in nature and as such does not add functional value; will not be given green signal. It is technical team and PM’s responsibility to provide necessary reasoning for bringing such work in scope. The time spent on rework when converted to dollars, the spent will be better understood. Such detailed analysis on dollar saving by refactoring work will be well understood and prioritized.
• Missed Scenarios & Impact Analysis…
  With requirements getting progressively elaborated and lack of understanding in the initial phase; we may face missed scenarios that are not initially estimated. Care needs to be taken to mitigate these risks and have plans to reduce the impact of such missed scenarios. Good plan usually has 5-10% contingency reserve and should take care of such misses. Careful categorization can help us identify all the change requests along with their estimation.

All such accepted changes, missed scenarios, risks and its mitigation plan, gold plating tasks, implied need tasks (such as default performance factor, providing LP – launch plans, Code review time, unit testing and bug fixing time, integration & bug fixing etc) must be updated in the plan. Few other important activities that are implicit and must be considered during planning are:

• Availability of resources along with their leave plans
• No. of hours available (hours/day)
  • I usually take 6 to 6.5 hours/day. Remaining time is used up in understanding the sprint backlog item, its design, in identifying various low level scenarios, getting clarifications to all the impediments. Since, we cannot add contingency reserve (as 5days) as one of the line items in the plan (mpp); the hours/day needs to tackle this need. 
• Getting business priority right for all the features
  • Listing all the sprint backlog items and its estimation
  • Identifying impacted area, dependencies and unknown area as line items
• Integration of Microsoft Project Plan 2007 works very well with TFS and assigns ID’s for all sprint backlog items.
• Tracking of each sprint backlog items story wise or sprint burn down by person wise helps

To avoid most of these common mistakes mentioned above, PM need to ensure consistency in watching risks, assumptions, dependencies, elaborated scenarios and changing the plan regularly. These days we rarely see waterfall projects to call out planning process as a one time activity. Plan changes all the time and hence is Agile in nature. The benefits of agile planning are multifold:

• Having early realization of business priority or value
• Regular feedback to ensure quality and provide the right solution.
• Early detection of risks
• Collaboration – tools like TFS and SharePoint play a very important role

 Before this blog takes different direction, let me stop here. Please feel free to write your comments…

Shrinath Inamdar Project Management

Do you use a CRM? We are guessing yes. Most likely that’s where your pipeline is maintained.

Does the invaluable discussion around an opportunity or deal happen inside the CRM. I am guessing No.  That’s your chat / IM solution.

Here is a simple solution that can leverage both these applications to ensure 360 degree communication. It can greatly enhance visibility and follow up of the pipeline opportunities and potentially increase the turnaround.

You can write a simple application to monitor your CRM system and push any interesting opportunity to the respective chat room or owner based on your business rules. This will ensure that any interesting information being captured in the CRM is surfaced on your primary communication system, maximizing the opportunity for collaboration.

In the example below I have an FX opportunity that’s just been created in the system and is worth more than a million dollars. As soon as it is saved in the CRM system, I get an alert in my chat window.

 

The link in the alert here provides single click access to the relevant opportunity for anyone interested in it.

 

As a corollary scenario, you would also want the valuable information generated while collaborating on such opportunities to get captured in your CRM system along with the context. This again can be achieved using a very simple Bot that lets you send Notes and update properties of specific objects in your CRM system.

In the illustration below, for a lost opportunity alert, user sends an update as free text from within the chat client which will automatically be added in the CRM system as an activity for the owner of the opportunity.

 

Here is how the text message from chat will appear in the Opportunity. Notice the highlighted activity.

 

So, this is a very basic integration example. However, the concept can be used to achieve far more sophisticated results and to automate workflows that can substantially improve your productivity.

Deepak Kumar MOSS, Microsoft, Unified Communications

 

Downloaded Visual Studio 2010 Beta 1 yesterday and as I was glancing through it strike to me that this version is stuffed, unless the previous two predecessors VS2005 & VS2008.
Framework has been more enhanced and visual studio IDE itself have got overhauled a bit. Well, I’m not going to give you a list of ALL features – it’s been blogged already around the world. Better Google it or Bing it with “VS2010+Features”

However, few notable features that caught my eyes are “Parallel Programming”, “F# - Functional Programming”, “Velocity – Distributed Caching”, “Azure Tools” and more important of all the evolving Team system.

But I first wanted to dirt my hand with Parallel Computing, because if you are a computer science student – well, you would be more excited about this than others.
Remember the big pillow sized books that we used to read to make this work? Well, things have changed and world have shrunk already. Though I cannot explain all the nitty gritty of parallel programming I will try this to explain in LAY MAN Terms.

Well, during the Stone Age [!] - Most of the computers in the world had only ONE Processors, except those big beasty servers which are always locked up in rooms with high security (well, usually *nix or Solaris servers) – these beasty servers used to manage most of the corporations. These servers had multiple processors and it took huge efforts to write software’s and manage them.

Welcome to the modern world – Every household and every laptop being sold these days at least have two or more processors.

Now – that has posed us a BIG Question? Hardwares have evolved, but has our software evolved to execute on multiple processors? – The answer is NO. At least not in the mainstream programming world – let’s say for example what would happen

1. If we execute a simple FOR Loop
2. That would call a service (that takes a longer time)
3. … and execute sequentially for N Times

On a single processor this is acceptable and we might use threads to increase the efficiency.

Is this still acceptable on a multiple processors? The answer is no. Fine, but how do we get efficiency without the hurdles of running and managing too many threads? Shouldn’t there be an easier way out for this?

Alrighty, without much ado, let me show you how easy(!) this is and a little insight on what happens behind the scenes. Let’s churn out a quick code here based on the same questions we have. Let us say a real long process (Well it could be about counting the stars in the UniverseJ, huh) and let us say you want to do this N times.

In our quest to count all the stars in the universe, let’s first create a data structure for the star and add to the universe, and let us use the good ol` mother of all loops the “FOR” Loop, and see how much inefficient this loop has become these modern days!!

 

“The Sequential execution took almost 30 seconds in my Dual Core Computer.”

And here is the Parallel Computing version of the same method. Yes, the for loop has been replaced with Parallel.For a new entry in System.Threading namespace.
How simpler can this get to?

VOILA! The Parallel execution took Just 3 Seconds in my Dual Core Computer.

Well, That’s a significant performance improvement without Hardware Scale-out or Scale-up, all we are doing is using the existing hardware resource efficiently. So much to a FOR Loop J, Huh. 30 Seconds of execution have become 3 seconds instantly. Look closer to the screenshot – the stars are not counted sequentially, instead it allocates the task to the available CPU in parallel.

Because the loop is run in parallel, each iteration is scheduled and run individually on whatever core is available. This means that the list is not necessarily processed in order, which can drastically impact your code. You should design your code so that each iteration of the loop is completely independent from the others. Any single iteration should not rely on another in order to complete correctly.

Let us catch up more on the insights soon on next part of the same series…

Logu Krishnan C#