Tuesday, October 15, 2013

How to accelerate any (Soft Ware) project

Now-a-days, I’ve been helping the pre-sales folks towards finalizing the prospective projects for our employer. In the recent time, one of our prospective client asked about the tips to accelerate any project from our experience. I’ve done some investigation and found the following points. I’m documenting here, such that, before I forget them and the effort in identifying these points should not end in vain.


1) Expand the team with dedicated developers towards each module – UnitDrivenDevelopment
2) Plan the build delivery
3) DB Management should be ongoing activity
4) Integrating testing as often as possible
5) Prioritize  the Interface Requirement Specifications (IRSs) as frequently as possible


1) Escape the probability approach
2) Avoid problematic functionality
3) Document the Traceability Index
4) Have the reality (nearly real) data with the developers
5) Plan for the asynchronous processing


1) Have the LOGs in place within Code
2) Plan the audit functionality for DB
3) Automate & escalate all Event / exception logs to the respective folks
4) Have the loosely coupled objects interact with a mutual contract pattern
5) Task driven user interface should be the theme of workforce
6) Think of XML/REST/JSON over ASMX/WCF/etc
7) REST over HTTP would be a great idea

Thursday, December 27, 2012

Self Managed Teams

This post is not about any technical concept, but about the concepts of a given team (or) the comparison of traditional and agile teams

Traditional Teams


SelfManaged Teams

Direction and Control

Manager's Role

Coaching, facilitation, and support


Responsibility for Performance


Top Down

Information Flow

Downwards, upwards and cross

Narrow, single-task roles

Job Role/Function

Whole process and multiple task

Top Down, imposed

Decision Making

By Team, within agreed boundaries


Authority Team



Development of team



This above table is taken from a magazine that is currently not in print. Executive Capsule is the name of the magazine.

Wednesday, December 26, 2012

Requirements of COM Architecture

This post might seems funny, writing about COM in the time of Cloud. Yet, this is a long time pending notes that I’ve prepared and are not documented. This is the time that I felt to document, of course, there are much information that is available on web. This would be an extra page that define the COM Architecture.

I see the need of this architecture in 4 directions.


Components must be compatible with the

1) application’s environment where they are used

2) and also with the components developed by the 3rd party vendors


Components must NOT require upgrades, if applications containing them are upgraded


Components must PERMIT development tool interoperability, while create any development tool (or) language during design time


Components must have an ABILITY to generate components that support not only function in process but also across process and networks ie., DOM


Final NOTE: COM is not a software, but a framework

Sunday, November 18, 2012

What type of Project is needed by your client?

Most of these days, everyone are moving to cloud apps. More or less, they are deciding to have their applications be available on web. Is it a trend or all requirements are demanding to become web apps?

Before we proceed further, from my understanding is that the need of the application decides the nature of the application, neither the investor nor any other party that is involved in the application life cycle. NOT EVEN THE END USER.

But how do we understand the nature of the application?

The below questionnaire helps in understanding the current requirement.

Sl Question Yes/NO/NA
1 Are your users comfortable using a Web browser?  
2 Are your users located in remote sites?  
3 Do your users in remote sites have access to the Internet?  
4 Are you creating a Business to Business (B2B) application?  
5 Are you creating a Business to Consumer (B2C) application?  
6 Is the amount of data entered minimal?  
7 Is the amount of data to display on the screen minimal?  
8 Is the number of fields on the screen fairly small?  
9 Does each user "own" their data?  
10 Are the same rows of data rarely updated by multiple users at the same time?  
11 Is this application mainly for light data entry, where speed of data entry isn't critical?  
12 Is there a lot of data review that requires "tall" pages?  
13 Do your users like to scroll through the data, as opposed to tabbing through data?  
14 Are there minimal data items on a screen that cause other data to change on that same screen?  
15 Can your users minimize the need to exchange data dynamically with other products running on the same desktop?  
16 Is performance a secondary consideration?  
17 Do your developers (or you) want to develop for the Web?  
18 Do your developers (or you) have the skills to develop for the Web (or can they quickly learn how)?  
19 Do you want a very graphically appealing look and feel?  
20 Do you have a lot of large screens that would warrant scrolling windows?  
21 Is it important to keep deployment costs to a minimum?  
22 Is it important to keep upgrade costs to a minimum?  
23 Will there be frequent updates to software?  
24 Can you hire/train Web programmers more cheaply than desktop programmers?  
25 Do investors and/or shareholders want a Web application?  
26 Would your users prefer a browser interface to a desktop application?  
27 Do users in remote sites have a high-speed connection to your internal network?  
28 Is it fairly easy to install Internet access in remote sites?  
29 When your users travel, do they usually have access to the Internet?  
30 The application interacts with other providers over internet (such as weather notifications, GPS, GIS, etc) ?  
31 Is this application only for one department?  
32 Is there a need to connect to special hardware?  
33 Do you need Drag-and-Drop support in this application?  
34 Are you designing a game, CAD, or CAM application?  
35 Do you need a lot of special controls for limiting data input (such as input masks)?  
36 Can deployment of this system be done through a network, by distributing CDs, or using push servers?  
37 The major portion of the user make use of this application from work desk?  
38 Is there a scope of gadgets usage in the near future?  
39 The application should function when the data is modified by other users? (And yet, warn the user before committing?)  
40 The application should have a facility for auditing the data manipulation?  
41 Can the application be hosted on intranet of the deployment location?  
42 The application doesn't demands the data sharing from online portals (such as XE for all the latest currency details) ?  
43 The count of the multiple users at any given point is greater than 10?  
44 The count of the concurrent users at any given point is greater than 1000?  
45 The users systems are built with Intel 'x'Core / Pentium technology?  
46 Are the user systems within the secured environment?  
47 There will be multiple versions of this application and buyers are licensed WRT these versions  
48 Can upgrades of this system be done through a network, by distributing CDs, or using push servers?  
49 The application does not demands extensive processing power?  
50 Can the application be split into different hosts, depending on the roles of the different users?  


Now that we have some understanding about the requirement, then how do we compile this information.

Step 1) Please replace all the Yes / No / NA with 1/0/-1 respectively from the below table

Step 2) Add the responses from Q1 to Q31 and store it separately

Step 3) Add the responses from Q32 to Q50 and store it separately

Step 4) Subtract  Step 3 result from Step 2 result

You would get a final number either +ve or –ve.

Response 1) Any number that is greater than 10, that is a need of WebApplication

Response 2) Any number that is less than 10 and a non-negative number indicates the need of a WinApplication

Response 3) Any negative number reflects as a smart client (or) split application architecture

Wednesday, May 30, 2012

Best practices for exception handling within .NET

While understanding the best practices for exception handling / tracking / etc., in the .NET, I’ve ended up with the below information

Best practices in Exception handling within .NET

Before identifying the best practices, it is mandatory to identify the exception generation situations and handle them to the best need of the situation. The below is the best scenario for the exception handling.


 Fig 1: Exception Workflow

[Source : Internet, I forgot the source link, but I’ve copied this above diagram. As soon I find the source, would mention here. In case if the reader came across of the previous article, please let me know

The above diagram is copied from Christian Thilmany’s blog post from this link.]

There are two ways of handling these exceptions

·         Catch them & Act Immediately

o   Early

o   Late

·         Catch them to Record (or) log & Act afterwards

Catch & Act

This mechanism is generally implemented in all the coding practices. This approach is implemented by the “try .. catch .. finally” key block. This is the finest mechanism provided by the .NET framework. Yet, this is very expensive to use and implement. The “try .. catch .. finally ..” causes an extra amount of memory management code. Thus, .NET framework provides a flexibility of custom exception classes implementation to handle them within the application. Hence we have the below 2 options

·         Usage of inbuilt TRY CATCH FINALLY is a SEH, ie., Structured Exception Handling mechanism

·         Implement custom EXCEPTION classes

Conclusion & Recommendation

Use the “TRY..CATCH..FINALLY” to catch the exception early and customize the exceptions into generic classes. Implement the needed functionality on the custom classes. Thus, I recommend to implement

1.       the “TRY..CATCH..FINALLY” block in all the unknown scenarios

2.       Implement a custom exception class for all the known exceptions

3.       Implement “TRY..CATCH..FINALLY” block only at the data layer

Record & Act

This mechanism is generally implemented in all the portals where the exceptions are not handled immediately thru coding, but for recording and the purpose of investigation. In this mechanism, all the exceptions are consumed by the code and recorded. These exceptions are not exposed to the end users. A generic message (or) a generic page is navigated when any source throws exception. Hence, the end user is not aware of the original exception message, which is recorded for future purpose.

Over periodic intervals these recorded exception messages are investigated and traced the root cause. There are various implementation practices for this kind of coding practice. One of the best mechanism is to have these exceptions caught and recorded at

·         Application level

·         Session level

·         Request level

All these exceptions which are caught at various levels are recorded at various means. The commonly used practice is to write them to event log under a specific EVENT log. It is not a WISE practice to write to generic event log.

There is various reusable exception handling frameworks that are available in the current world. The below are the few names that are popularly used.

·         EHAB : Enterprise Library Exceptional Handling Application Block

·         Log4net : Widely used by industry  in the previous years

·         ELMAH : Acquiring the industry adaption as the new versions are finding this as friendly

The best practice of these recordings done by these tools is to a variety of locations like the below mentioned

·         The event log

·         An e-Mail message

·         To Database

·         A Message Queue

·         A Text file

·         WMI Event

·         Custom format and locations. XML formats, encrypted formats, etc .,are stored at network drives


Conclusion & Recommendation

Use the “TRY..CATCH..FINALLY” to catch the exception early and customize the exceptions into generic classes. Implement the needed functionality on the custom classes. Thus, I recommend to implement

1.       The “TRY..CATCH..FINALLY” block ONLY in all the unknown scenarios

2.       Implement a custom exception class for all the known exceptions

3.       Implement “TRY..CATCH..FINALLY” block ONLY at the data layer

NOTE: I highly recommend to the implementation of ELMAH. But we need to have a process in place to investigate and deal the exception.

On top of all, in the bottom line of my heart, I’m an ardent believer of “not using the TRY CATCH block”. Thus, most of my code is written without TRYCATCHes. I’ve been successful all these days. Need to learn where would I fail so that I start use the TRYCATCHes

Browser control in .NET

Yesterday, I had to give some recommendations of using the browser control in windows application. The following text is submitted to the client and I’ve learned the deep hidden facts of the browser control. Below are the points of my discovery and they were extremely interesting if we dwell deep into it.

Browser control in .NET

There are 2 mechanisms that are supported by .NET to make the web URLs get data into windows applications. These mechanisms use components from

·         shdocvw.dll (the default WebBrowser Control which supports IE 4.0+ ) supported by ieframe.dll (the Core engine for IE 7+)

·         A COM component by Microsoft as “Microsoft HTML Object Library” in the form of mshtml.dll.

These both mechanisms have their purpose defined for specific need. These two flavors are available from .NET framework, thus, they work independently from the IE installation on the application runtime machines. Hence, it doesn’t matter whether the runtime machines / client machines are installed (or) not with any version of IE.

Default WebBrowser

In the majority of situations, it is better to directly host the WebBrowser rather than MSHTML. This is because the WebBrowser supports in-place navigation, history, and so on—in other words, it encapsulates the expanded capabilities of the browser.

The default WebBrowser control which inherits from WebBrowserBase is like any other control of Windows form. This WebBrowserBase Provides a wrapper for a generic ActiveX control for use as a base class by the System.Windows.Forms.WebBrowser control.


Microsoft HTML Object Library | MSHTML

One great point with MSHTML host can load and display the pages from URL or Files asynchronously. If you host MSHTML directly, you gain the use of an HTML and Cascading Style Sheets (CSS) parser and renderer, but you cannot take advantage of the browser's other capabilities.

MSHTML gives a great flexibility for the developer to customize the business need and workflow. MSHTML knows the states of URLs (or) HTML pages. Thus, when the ready state of the document changes, MSHTML calls the host's implementation of IPropertyNotifySink::OnChanged. This is a handle for implementing any piece of code in the INotifier pattern

Conclusion & Recommendation

The decision to use which methodology depends on the business need and the requirements of the user story. Thus, I recommend using

·         the default WebBrowser if there implementations demands all the Browser navigation

·         the MSHTML if the CSS plays a vital role in the requirement

One final point of attention from this study is the automatic event delegation possibility for the MSHTML. If there is much time, I might explore this functionality.