Polarity Management

A recent article in the San Jose Mercury news talked about the inherent polarities of being a manager and how the Polarity Management concept can be used to deal with the complexity of working in an organization.

Polarity Management concept basically about how to deal with two conflicting points of view and both of them true.

One of the examples of polarities that this article gave was:
"You get a new boss, who is very focused on productivity. He's hard-nosed and impatient. Yet you've built your success on being a manager known for your ability to mentor employees and keep harmony on our team. The new boss doesn't care about that stuff."

Polarities certainly provides many challenges to a manager. Season and smart managers are more equipped to deal the challenges than new managers. This article outlined several helpful techniques to handle challenges:

1. Accept that you are part of the management
• Agree to represent the leadership of the company in meeting business goals
• Don't cut off relationships or refuse to hear the point of view of your employees
2. Be clear about the personal benefits of being a manager
• Remind yourself of the enjoyable times when feeling stressful in dealing with polarties
3. Know your boundaries
• It's OK to acknowledge there have been disagreements about a decision and move on

I certianly enjoyed learning about the Polarity Managment concept from this article and now I can recognize the concept the next time it occurs in my workplace. Also now I know what techniques can be used to deal with the challenges that a polarity situation brings.

Framework vs Library

Definition of a framework:

1) "A reusable desing of all or part of a system that is represented by a set of abstract classes and the way their instances interact". (Reference 1)
2) "The skeleton of an application that can be customized by an application developer."(Reference 1)

Framework allows developers to reuse more than just code, the design and architecture reuse is important. Framework provides a structure where an application must follow certain flow and contracts. It provides a skeleton and unlike a class library, this one is active in that it has its own execution path, in other words the control is inverted where the container will call the application. Frameworks are a kind of domain-specific architecture.

Often time, framework leverages on design patterns to achieve flexibility and provide a general-purpose application design. Design patterns helps in creating indirections and abstractions so you can plug in your own classes. Frameworks are at a different level of abstraction than the design patterns. Design patterns are the micro-architectural elements of frameworks. Another way of looking at this is that a frameworks usually contains my design patterns.

Benefits of a framework:
1) Efficient, easy to maintain and reliable
2) Reusable context for components
3) High productivity
4) Design reuse

Despites all the benefits of reuse, using a framework requires investment in learing the framework's interactions and limitations. It is important to understand the following characteristics of a framework:

1) Strength
2) Weaknesses
3) Target applications
4) Its component and structure
5) Development process
6) Fundamental design patterns
7) Programming techniques

"Frameworks are firmly in the middle of resuse techniques. They are more abstract and flexible than components, but more concrete ans easier to reuse than a pure design." (Reference 1)
Reference:
1) Frameworks = (Components + Patterns) by Ralph E. Johnson

Extreme Programming

Extreme summary of the Extreme Programming methodology



Common Ideas:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiations
• Responding to change over following a plan

Values:

• Communication - Provides the team with an avenue for expressing ideas, thoughts, understanding and innovation
• Feedback - provides the team with a way to determine the effectiveness of what they are doing
• Simplicity - keeps the team from getting bogged down and over-complicating the application
• Courage - necessary to just do the right thing, even when that is not always the path to least resistance

Practices:



Planning game, small releases, continuous testing, simple design,

coding standards, pair programming, collective code ownership,

refactoring (cut/paste), continuous integration, metaphor and sustainable pace.



The real benefits that we can gain from XP are:

1. Produce high quality software
2. Increase team communication
3. Software development will be more fun

Design Pattern

A collection of good websites and articles about software design patterns:

1. GoF Design Pattern Quiz


2. Memento Pattern


3. Core J2EE Design Pattern
   

Ask More Why Questions

One of the advises about how to get ahead of the pack that I got is to ask to right questions when facing a decision or in a group discussion. A recent article in the Computerworld magazine echoed the same suggestion.

This is easier said than done. We are so wired to be the answer people. Since the kindergarden days, we were so conditioned to answer the questions that were asked by our teacher. The first one that can answer the question correctly is often time recognized and rewarded.

In the working world, most of us under utilize our critical thinking ability. We don't ask enough of the "Why" questions. Maybe we don't want to spend the time to scrutinize the issue or assume that our concerns are already addressed by others. Or we don't want others to think that we ask too many questions. The key is to ask the right question at the right time. Here are a few rules that was suggested in the Computerworld magazine:

1. Prioritize your questions - handle the most threatening things first.
2. Why question should precede what, how, who and when questions.

Furthering one's career requires dedication to utilize more of our critical thinking ability so we can start asking good questions.

Understanding Classloader

Classes in a Java virtual machine are constrained to the scope of their class loader environment. A class loader can spawn multiple child class loaders, in effect this will create a class loader
hierarchy. There are two basic rules:

1. The class visibility rule: a child class loader can "see" up the hierarchy, just like children can use their parent's money, but not the other way around. This is known as the "Visibility Contstraints" rule.
2. The class resolving rule: a child class loader will ask the parent class loader to load a particular class. Only when the parent' can't, then the child will attempt to load the needed class. This is known as "Delegate Load Request" rule.

A class loader can have siblings, but can't share classes that are loaded. Usage of such a shared class will result in

ClassCastException.

So the challenging is how to share a class across siblings given the above constraints. First we must understand the class loader boundaries and then use a strategy that works within these boundaries:

1. System level class loader: load J2SE and J2EE classes
2. EAR level: load every jar and war file in an enterprise application. Classes loaded at this level can access one another.
3. WAR level: load classes from /WEB-INF/classes and WEB-INF/lib directory. Classes at this level can access classes at EAR and System level.

Project Management

How important is applying good project management practices in a project? In my opinion, it is very important, yet many companies place very little emphasis in this area. A good project manager can make a big difference in a team to help in guiding a team out of troubled water and improve team moral.

Here are some good and common sense project management practices from a recent article in ComputerWorld magazine:

1. Every hour of planning would save three hours of work.
   
2. Tailor a life-cycle development methodology to a project, team and
   organization culture.
   
3. Communicate often and early - the last thing you want to do is to have
   one kick-off meeting at the beginning of a project and then have another
   meeting later in the project trying to salvage it.
   
4. Use key words in subject of emails which will allow Outlook to filter
   project related emails easily
   
5. Indecision can kill a project, be persistent in driving to a closure.
   
6. If a technical problem is not solved in 8 hours, escalate it and get help.
   
7. Use Extreme Programming stand-up meeting practice to ensure problems are
   addressed and to reduce surprises.
   
8. Know when to say done. Remove as much uncertainty as possible toward the end
   of a project. Limit checkins.