Reacting To Change Requests

Change is not inherently bad or good. However, the team can react to changes in positive and negative ways, depending on the state of the project. A typical reaction from most project teams is to just go ahead and make the changes. However, there is another reaction that can be more problematic. The team may not want to make any more changes. This situation usually occurs on projects that have had problems and could be for a variety of reasons.

  • This may be a long project, perhaps requiring overtime, and people just want the project to end.
  • The proposed changes will require a lot of work, and the deadline date is being held firm. Again, overtime may be required from the team.
  • Members of the project team and the client have not had a smooth relationship on the project. There may be project team members that do not want to help the client further.
  • The changes require major upstream rework to the design, which will require changes to construction and re-testing of the entire solution.

All of these situations (and more) result in a scenario where the project team is not motivated to support scope changes. This puts the project manager in a tough position where he or she has to get the rest of the team on board for one last charge.

Frankly, it’s a tough sell. The team is tired and they are not motivated. In fact, morale may be poor. However, this is the time for the project manager to show leadership. Since the cause of the team problems is probably complex, the solution should be multi-faceted as well. Here are some things for the project manager to consider.

 

  • Explain the facts first. Do not start with a rah-rah speech right away. First meet with the team and explain the background and circumstances. Then talk through the changes that are needed and why they are important from a business perspective.
  • Acknowledge the pain. The project manager must acknowledge the problems. Let the team know that you understand that they may not want to make the changes and that their morale is poor. Don’t dwell on it – but acknowledge it.
  • Be motivational. Now is the time to motivate the team. Appeal to their sense of working together as a team to get through this adversity. Let them know the value they are providing to the company.
  • Talk to everyone one-on-one. In addition to the team meeting, talk to the entire team one-on-one to understand where they are at mentally. Listen to their concerns and get their personal commitment to work hard and keep going.
  • Get management and the sponsor involved. Now is also a good time to ask your manager and your sponsor to talk to the team, thank them for their work so far and ask for their continued help getting through the changes.
  • Look for perks. Little perks can help a team get through motivational and morale trouble. These can be as simple as donuts in the morning and pizza for those that have to work late overtime.
  • Make sure the clients are in there with you. Normally if the project team is working extra, the clients are sharing the pain as well. However, the project manager should make sure they are.
  • Communicate proactively. Keep everyone informed as to the state of the project and the time and effort remaining. If the project manager starts getting closed and secretive with information, it causes many more problems to morale.
  • Celebrate successes. The project manager does not need to wait until the project is over to declare success. Look for milestones, or mini-milestones, as opportunities to celebrate a victory and give praise to team members.

A project manager needs to have more management and leadership skills than simply telling people to “do their jobs." This is a tough situation and requires good people management skills to get through successfully. Success is never guaranteed, but utilizing some of these tips can help the Project Manager get through a tough situation.

Advertisements

C#2.0 Anonymous methods

 

 

All methods use a subset of elements from the same master set. In C# 2.0, the set of optional elements will grow. Historically—except in C++ inline methods—methods required a name, a return type, and a body. Optionally, methods could use an access modifier and a parameter list. In C# 2.0, the method name has been moved from the list of required items to the list of optional items.

C# 2.0 (and .NET in general) introduces the anonymous method. An anonymous method can be used anywhere a delegate is used and is defined inline, without a method name, with optional parameters and a method body.

Anonymous methods are a condensed way to declare and use delegates. Delegates started life in languages that preceded .NET languages, as pointers to function signatures. A delegate is a class that encapsulates the pointer; implicitly, delegates in .NET are multicast delegates. To be a multicast delegate simply means that the “one function to one pointer” limitation is gone, because the multicast delegate class contains a list of pointers. The inclusion of an internal list means that the address of more than one function can be assigned to a single delegate. When the delegate—think “event”—is raised or invoked, all of the internally listed functions are called.

 

In C#, the addresses of functions are inserted in a list via an overloaded += operator and removed via an overloaded -= operator. C# also supports manually defining add and remove blocks; add and remove are to delegates what get and set are to properties.

In C# 1.0 and C# 1.1, we typically assign instances of delegates to event properties. For example, in WinForms a Button control exposes a Click event. The delegate type of Click is EventHandler. EventHandler is a method that takes object and EventArgs arguments. Hence, we can initialize an EventHandler object with any method matching the delegate Event Handler’s signature and assign that delegate to Click. Here’s how the code might look:

private void Form1_Load(object sender, EventArgs e)
{
    button1.Click += new EventHandler(OnClick);
}
 
private void OnClick(object sender, EventArgs e)
{
    Debug.WriteLine("button1 clicked");
}

Because the forms designer for WinForms and the page designer for WebForms automatically add the code for delegate binding, it’s possible to write a lot of code without binding delegates manually.

Anonymous Methods Are Inline Delegates

Generally, when we’re using delegates, we have a method. That method’s signature matches the signature prescribed by a delegate and can be used to initialize a delegate instance. Anonymous methods are used to condense the method and initialization of the delegate into a single location.

Using the example from the previous section, we see how the instantiation of the delegate new EventHandler is distinct from the method OnClick used to initialize the delegate. This code could be compressed into an anonymous method:

private void Form1_Load(object sender, EventArgs e)
{
  button1.Click += delegate
  {
    Debug.WriteLine("button1 clicked");
  };
}

To create the anonymous method, notice that we removed OnClick‘s method header and replaced the construction of the EventHandler delegate with the word delegate followed by OnClick‘s method body. The resultant behavior is the same. If we want to use the event arguments we would normally find associated with the delegate, we can add an optional parameter list after the word delegate:

private void Form1_Load(object sender, EventArgs e)
{
  button1.Click += delegate(object s, EventArgs ev)
  {
    Debug.WriteLine("object is " + s.ToString());
  };
}

If you define delegate parameters, they must match the parameters defined by the delegate type. For example, Click‘s type is EventHandler, so if arguments are present they must match EventHandler‘s arguments object and EventArgs.

Anonymous methods can be used wherever delegates are expected. Anonymous methods can use ref and out arguments, but cannot reference ref or out parameters of an outer scope. Anonymous methods can’t use unsafe code, and anonymous methods can’t use goto, break, or continue in such a way that the branch behavior causes a branch outside of the anonymous method’s code block.

Use of Anonymous methods

Anonymous methods are good because they reduce code overhead caused by instantiating delegates and reducing separate methods. But the marketing material also says that anonymous methods increase usability and maintainability. I thought well-named methods did that. Does this code look easily maintainable?

private void Form1_Load(object sender, EventArgs e)
{
    BindClick(delegate { Debug.WriteLine("button1 click"); });
}
 
private void BindClick(EventHandler handler)
{
    button1.Click += handler;
}

In this sample, we’re passing a delegate to a method by passing the delegate as an anonymous method. Just keeping the order and number of the parentheses, semicolons, and brackets straight is a pain in the neck.

The cited classic example is that anonymous methods can reduce the overhead of creating delegates and methods just for kicking off threads (which use delegates). This is true, but threads are used infrequently and are already difficult enough to use correctly; I wonder how prudent it is to make the code more esoteric rather than less.

Anonymous methods are examples of methods without names that can be defined and used anywhere a delegate can be used. Delegates are wrappers for event handlers. How practical and generally useful anonymous methods are remains to be seen. I suspect that anonymous methods will be much less useful than overloaded operators and used even less frequently, but anonymous methods are part of .NET and it’s useful to recognize them when you see them.

 

Post-Cache Substitution

 

ASP.NET 2.0 now supports post-cache substitution, which allows you to configure a section in a page as non-cacheable. Therefore, although the page is cached, parts of it will be re-processed when the page is requested again. For example, you can create a cached page with mostly static content but that displays the user’s name in a Label control. Without post-cache substitution, the user name would remain the same for all requests. With post-cache substitution, you can mark the page as cacheable and put the Label control inside another control marked as not cacheable. The user name will then refresh each time the page is requested

 AdRotator Support for Post-Cache Substitution

Although it is possible to insert dynamic content from user code as demonstrated in the examples above, the most common way that page developers will access post-cache substitution behavior is through ASP.NET server controls that implement direct support for it. For example, the ASP.NET AdRotator control implements support for post-cache substitution in order to render unique Advertisements on each request, regardless of whether the parent page is cached.

<%@ OutputCache Duration="60" VaryByParam="none" %>

<form runat="server">

<asp:AdRotator AdvertisementFile="Ads.xml" runat="server"/>


</form>

Internally, the AdRotator creates a standalone in-memory object with a single callback method that can render Ad content, to be passed as the delegate to the Response.WriteSubstitution method. This render object retains enough context for each of the AdRotator’s user defined properties to be able to generate Ads independently of the page.

 

Response.writeSubstitution

 

 

ASP.NET v1.x introduced a powerful feature known as Partial Page Caching. This feature allowed developers to construct ASP.NET pages which were partly dynamic and partly cached. Regions marked as dynamic are executed on each request while areas marked as cached are executed only once and cached until a specific dependency is enforced. The cached regions are separated into user controls with appropriate cache directives, and the dynamic content either remains in the parent Page or is contained in user controls without cache directives.


This partial page caching approach works very well for scenarios where most of the page content is dynamic and/or it is easy to encapsulate cached content into isolated user controls. It does not work as well for the inverse scenario, when the majority of page content should be cached and only a small portion is to be dynamic. For example, consider a page of news stories extracted from a database, which contains a single rotating advertisement. In this scenario, the news stories (and surrounding page header, footer, and site navigation interface) might be easily cached, since they change relatively infrequently. However, the rotating advertisement should change on each page request, to display a random advertisement to each site visitor.

ASP.NET Whidbey introduces a new feature called Post-Cache Substitution, which is aimed at optimizing the development experience for this mostly-cached page scenario. Rather than requiring page developers to mark page regions (user controls) as cached, post-cache substitution allows them to output cache an entire page and then simply identify regions of the page that should be exempt from caching. It also allows control developers to prevent their rendering from from being cached. In the above example, an AdRotator control that takes advantage of post-cache substitution would be able to serve a different advertisement on each request even if its parent page were cached.

Using the Substitution API

Page developers can easily take advantage of post-cache substitution in their output-cached pages. A developer simply writes a method with a prescribed SubstitutionCallback signature that takes a single HttpContext parameter and returns a String, which is the content to substitute at a given location. The developer then calls Response.WriteSubstitution, passing the callback method as a parameter. The callback method can either be a static method on the containing Page or UserControl, or a static or instance method on another arbitrary object, and must be thread-safe.

<%@ OutputCache Duration="60" VaryByParam="none" %>  
<script language="C#" runat="server">    
public static String GetCurrentDate (HttpContext context) 
{     return DateTime.Now.ToString();   }  
</script>  
... cached content ...  
<form runat="server">   
<% Response.WriteSubstitution 
(new HttpResponseSubstitutionCallback(GetCurrentDate)) %>  
</form> 

On the first request to the page, WriteSubstitution performs these steps:

1.       Calls the HttpResponseSubstitutionCallback delegate to produce the output.

2.       Adds a substitution buffer to the response, which retains the delegate to call on future requests, as well as the first-time output from step 1.

3.       Degrades client-side cacheability from public to server-only, so that the will not be cached on the client, ensuring future requests to the page re-invoke the delegate.

On subsequent requests, the cache module intercepts incoming requests and retrieves the associated stored buffers. When writing the substitution buffer, the delegate is invoked to produce new output, which is written to the response.

 

 

10 myths & facts about working in the Indian IT industry

 

 

India’s booming information technology industry already hires more than a million employees and the numbers are set to grow manifold over the years.

Yet, the Indian IT sector, which has brought India on the global map (far removed from the West’s perception of India being the land of diseases, poverty and snake charmers), is still grappling with the issue of high-end and low-end jobs and seeking out ways to go up the value chain.

Here are the 10 myths and facts about IT industry that you must know.

Myth #1: Company A has offered more salary than Company B, so it is better than Company B.

Fact: A bigger salary does not always mean better job-satisfaction. Big companies (with good cash flows) can afford to give more salaries than other relatively mid-sized or small companies or start-ups.

Also some companies outsource loss-making units or less revenue-generating product and maintenance work to India to cut costs, so job satisfaction for someone more interested in work content than the money is going to feel low.

For start-ups and small companies, salaries might not be very good, but they might offer stock options or bonus to compensate for this. Also work content in these companies might be better than big companies.

Some venture capitalists in the United States, when looking to fund start-ups, have begun to ask those companies whether they have an India-specific plan. Since these companies work on new/innovative products, work content is likely to be good.

Myth #2: Let me join Company A. If I don’t like it, I will leave it and find a better job elsewhere.

Fact: Unless you are very clear about your goals and ambition you will keep changing jobs time and again. The best thing is to decide what you want to do quite early on in your career.

However, this seems a daunting task. This is true for someone with less than 3-4 years’ experience and has no idea about the industry and what one wants to do. In addition, most of the companies hiring from campuses do not decide in advance what project the selected candidates will be working on. Later on, when works get assigned it does not match one’s ambitions.

Also, most institutes/colleges put restriction on the number of job offers one can accept, so the selection of companies is not by choice. However, if you have joined a company that works on specific areas that are not to your liking then it is best to look out for another.

It is quite difficult for the company to find something that is specific to your interest, as it is beyond its scope. However, for you next job search, you should clearly indicate to your prospective employer that you are looking to work in a specific area (it is advisable to specialise in one domain/work area) and whether the company does that kind of work and you can be involved in that work.

Do not put off asking this after joining as it would be too late by then. It is best to give multiple interviews and decide on the one that best matches your aspirations. Don’t let salary be the lone criterion when you make your decision.

Myth #3: Infotech work is more of ‘a routine job.’ No high-end work gets done in India.

Fact:This might be true in many cases, but the opportunities to work on challenging and complex projects is increasing in India. Currently, very few companies (rough estimate: 10-15%) in India are doing this. If you are the brainy type, seek out such companies. Using the best brain to do routine jobs can lead to job-dissatisfaction soon.

Also, most companies that launch their operations in India tend to give easy assignments in the beginning and you might feel that the job content is quite simple. But the important part is that is once you finish the project to the satisfaction of all stakeholders, the overseas management becomes confident in offshoring more complex work.

If the management is not convinced, then you will continue to do the daily chore. So, the bottomline is that if your team delivers quality product on time, you will get good work in the future.

Myth #4: Only product companies do exciting work.

Fact: The fact is that the typical work content in product companies involves a mix of routine and challenging tasks. In product companies, delivering a quality product is of great importance and as a result a typical product release involves multiple rigorous testing and bug-fixing phase.

This is a typically mundane and repetitive task and not always interesting. But it is important to understand that this is a critical task from company’s perspective, as nobody would want to deliver a buggy product in the market and lose customer confidence.

So you cannot just focus on design and coding, and ignore testing and bug-fixing. Not only this, you should be flexible enough to work in any area whether you like it or not. You get both exciting and non-exciting work in the long run.

Myth #5: The Indian IT industry cannot offer the kind of job requirement I am looking for.

Fact: It requires a lot of effort to select the company of your liking. With so many companies setting up shop in India, this has made things even more difficult. Don’t follow the principle ‘my friend is working there, so I should follow him/her.’ The requirement of your friend might be different from yours and you should seek companies that meet your requirement.

For experienced people, it is best to go through recruiters and indicate your exact requirement to them. If the recruiter is good, he will shortlist the companies that meet your expectations. If you find that the recruiter is not going by your interests, look for another recruiter.

Myth #6: I received a mail from a placement service saying that the job openings it has matches my profile.

Fact: Most of the recruiters/placement services send bulk mail to all and sundry. They do not scan resumes properly and just match keyword(s). Personally, I have received mails from recruiters, who say that my profile matches the job they have on offer, but if I look at the opening it does not match at all.

It is best to clear this with the recruiter before you agree to appear for an interview. This saves you the embarrassment of being on the ground that your profile/experience does not match the job profile.

Most companies rely heavily on recruiters for non-fresher openings and if they do not filter the candidate correctly, then most likely HR will not filter it either and call you for an interview!

Myth #7: Working abroad is better than working in Indian companies.

Fact: This might not be always true. If you are going to work as a consultant in the US, you might land up a worse job than what you were doing in India. With the IT doom of 2000 there is a very small pool of highly qualified professionals available in the US and they normally get better jobs than Indian consultants do.

Typically, in product companies, consultants are hired to do less critical work or work that can be done easily. If your expectation is to do high-end work, you will have to wait longer to do it. It is a much better option to obtain a master’s degree from top-rated university in the US to bag better jobs.

Product companies usually hire the best brains from these universities to do the challenging work for them. Also the biggest advantage of working overseas is that you get to work with the best brains and learn a lot from them. It typically takes 4-5 years of overseas experience to get a good understanding of the overall execution of software products.

Myth #8: Management ladder is a much better option than technical ladder. Fact: If you are the kind who loves to be technical, look for an organisation that encourages career growth for core technical work and pays salary at par with management salary for the same zone.

The demand for senior technical and senior architect professionals will grow as more high-end, specialised work gets done in India. Some companies have both managers and architects in the same project.

The manager takes care of the people and project execution, while the architect takes care of all technical aspect of the project. For complex and large projects, it is not possible for the manager to wear, both, the technical and the managerial hats, and hence the need to hire architects to take care of all technical aspects.

If you find the employer saying that you will be doing 20 per cent management and 80 per cent technical work, treat the statement with caution. Most likely it might turn out to be the other way around!

Myth #9: I am working abroad. If I relocate and work in India I won’t get the same job satisfaction.

Fact: This is no longer true. The nature of the jobs done in India is as good as that in the US or other countries. The only difference is that the products that are futuristic in nature are not so prevalent in the Indian IT industry. In addition, career growth in India is much better — and faster — than overseas.

Myth #10: My satisfaction with the Indian IT industry is not in my hands.

Fact: As stated in the facts to the above myths, you yourself are solely responsible for job satisfaction. You have to research well when making a career plan and ensure you are at the right place.

 

RUP-Class Design

 

1.       Class operations, attributes, relationships, methods, states, dependencies, implementation requirements, interface realizations

 

2.       ·Outline design classes

·          boundary classes mapped to user interface technology (e.g. forms, controls, charts, …)

                                                               i.      screen design tools implicitly define boundary classes

·          entity classes mapped to persistent technology

                                                               i.      object-relational mapping, database design, data modeling, etc.

·          control classes must consider distribution (separate design classes on different nodes), performance, and transaction issues.

 

3.       Identify operations and visibility in language syntax  

·          responsibilities, inputs and outputs

·          special operations

·          interfaces provided

·          flow of events descriptions

o         activity diagrams

o         state diagrams

·          Support and coordinate all roles the class plays in different use-case realizations

 

4.       Identify attributes

·          type based on programming language or design class

·          cannot share a single attribute among design classes, make it a separate class

·          refactor complex classes – separate concerns

 

5.       Identify associations and aggregations

·          see interaction diagrams

·          multiplicities, role names, association classes, ordered roles, qualified roles, n-ary associations, navigability

 

6.       Identify generalizations

7.       Describe methods, as necessary (defer to implementation)

8.       Describe states and state chart

9.       Handle special requirements

10.    Refactor mercilessly during iterations

 

RUP Use-Case Design

 

 

 

1.       Identify participating design classes: derived from analysis classes in analysis-level use-case realization, derived from special requirements on a use-case realization, or discovered during design

 

2.       Describe design object interactions as one or more diagrams of sequences of messages among actor instances and design objects

·          Use case invoked by a message from an actor to a design object

·          Each participating design class should have an object in at least one diagram

·          Messages should be (or become) operations on the receiving object’s class

·          Use labels and textual flow-of-events to complement the diagrams

·          Sequence diagram should handle all use case relationships (generalizes, extends, etc.)

 

3.       Identify all alternative paths, especially new ones

·          Time-outs when nodes or connections fail

·          Erroneous input

·          Error messages and exceptions

 

4.       Identify participating subsystems and interfaces and show interactions at sub-system level

·          more coarse granularity than classes/objects

·          Identify bottom-up and/or top-down

·          Fine-grained ßà Coarse-grained

·          Capture implementation requirements