Characteristics of a Leader

The following is coted from the book Analyzing Requirements and Defining Solution Architectures.

Finding Effective Leaders

For the person in charge of putting together a project team, the first task is to decide who will work on the project. This seemingly simple (but more often complex) decision can dramatically affect the project's outcome.

Finding leaders within an organization is not a difficult process. By definition, leaders are recognized by those they work with. It's important to remember that we are talking about leaders here, not bosses. Every organization has its share of managers, directors, and so on, but the hierarchical structure of an organization does not determine who the true leaders are. Actions and characteristics, rather than job titles, identify leaders.

Why do we need leaders? Because we have so many followers. It's important to realize that labeling people as leaders and followers does not imply a value judgment. We must have leaders to be successful, but we must also have followers. Leaders provide direction for the team. Followers get the work done. The team needs to strike a balance between its leaders and followers. It must decide what to do and then must do it, so both leaders and followers are equally important and valuable. An absence of either leaders or followers will hinder the project's success.

Certain characteristics are present in many leaders. Common qualities of leaders include:

• Understanding and meeting the needs of others.
• Communicating well with groups and individuals.
• Earning the respect of internal and external customers.
• Displaying commitment to well-defined purposes.
• Making a positive difference.
• Having confidence in his or her abilities.
• Practicing good problem-solving skills.
• Helping others to develop their skills.

Many people will read this list and say, "I do those things." More people will read this list and say, "I intend to do those things." But being a leader also means knowing the difference between intent and impact. When measuring their own success, people measure their intent; when measuring other people's success, they measure their impact. The impact that leaders have on others may or may not be their intent, and leaders' intent may not have the impact they were striving for. The proper way to measure people's leadership skills is by the impact they actually have, not by their intent. We can summarize this concept by saying, "Other people's perceptions are reality."

Total Participation in Design

Jim McCarthy summarizes the concept of total participation in design in Dynamics of Software Development:

The goal in any product design is to have the best ideas become the basis of the product. Everybody on the team should be working to accomplish that goal.

Each role participates in the generation of the Functional Specification because each role has a unique perspective of the design and tries to ensure that the design meets their role's objectives, as well as the project team's objectives.

 

Project Goals and Responsibilities

The folowing is coming from a paragraph in Chapter 3 of Analyzing Requirements and Defining Solution Architectures.

Specific responsibilities must be carried out and specific goals must be met in order for any project to be successful. These responsibilities and goals serve to provide continual direction for all the team members. Key project responsibilities and goals include the following:

• Customer satisfaction Projects must meet the needs of their customers and users in order to be successful. It is possible to meet budget and time goals but still be unsuccessful because customer needs have not been met.


• Delivery within project constraints Most projects measure success using "on time, on budget" metrics.


• Delivery to specifications based on user requirements The Functional Specification describes in detail the deliverable to be provided by the team to the customer. This specification represents an agreement between the team and the customer as to what will be built, and constitutes the basis for "Doing what we say we will do."


• Release after identifying and addressing all issues All software is delivered with defects. The team's goal is to ensure that those defects are identified and addressed before the product is released. Addressing defects can involve everything from fixing the defect in question to documenting work-around solutions. Delivering a known defect that has been addressed along with a work-around solution is preferable to delivering a product containing unidentified defects that may "surprise" the team and the customer later.


• Enhanced user performance For a product to be successful, it must enhance the way that users work. Delivering a product that is rich in features and content but can't be used is considered a failure.


• Smooth deployment and ongoing management The effectiveness of deployment directly affects the perceived quality of a product. For example, a faulty installation program may imply to users that the installed application is similarly faulty. The team must do more than simply deploy the product; it must deploy smoothly and then support and manage the product.

NOTE

---

Many factors can affect a project, some of which will constrain it. When the project team focuses on meeting the agreed-upon goals of the project and delivering the product on time, it ensures that the organization receives the right Return on Investment (ROI), which is the right product for the right price.

Goals and corresponding team roles:

Customer satisfaction by Product Management
Delivery within project constraints by Program Management
Delivery to product specifications by Development
Release after identifying and addressing all issues by Testing
Enhanced user performance by User Education
Smooth deployment and ongoing management by Logistics Management

Anonimous Functions in C# 3.0

These parts are coming from the Language Specification document:

x => x + 1 // Implicitly typed, expression body
x => { return x + 1; } // Implicitly typed, statement body
(int x) => x + 1 // Explicitly typed, expression body
(int x) => { return x + 1; } // Explicitly typed, statement body
(x, y) => x * y // Multiple parameters
() => Console.WriteLine() // No parameters
delegate (int x) { return x + 1; } // Anonymous method expression
delegate { return 1 + 1; } // Parameter list omitted

// Example:
delegate bool Filter(int i);
void F() {
Filter f = (int n) => n < 0;
list.FindAll(f);
}

delegate void D();
void F() {
int n;
D d = () => { n = 1; };
d();

// Error, n is not definitely assigned
Console.WriteLine(n);
}

Distinguish Design time in ASP.NET

From MSDN site:

The easiest method to check if the control is at design mode is simply to check the current HttpContext. If this variable returns Nothing, then the control is in design mode.


Private Function IsDesignMode() As Boolean
Try
If HttpContext.Current Is Nothing Then
mboolDesignMode = True
Else
mboolDesignMode = False
End If
Return mboolDesignMode

Catch
Throw

End Try

End Function