Towards a smoother project transition

Disclaimer:

All the challenges and solutions presented in the article below have evolved out of my experience I have had till date working with a single customer project. Hence at times, you may feel that my thoughts are getting narrowed down and their applicability to a large number of projects, is fading out; don’t worry. Any such outcome is purely the result of my lack of experience of having worked on diversified projects.  Hence request you all to take them with a pinch of salt.

In my previous article [Things to watch out for during a development project] I had shared with you all the challenges we faced while executing a development project. This article however focuses on challenges I see in dealing with the transition phase a project.

• Overcoming the inertia and accepting  the changes more realistically

This is probably the first thing everyone in the team, right from the developer to the manager, should come to terms with. They ought to appreciate and then accept the fact that development phase of the project phase is over, and the project has now entered a new phase, the maintenance phase. It is very important to understand that a development project and a maintenance project are not the same. Maintenance projects are a different ball game altogether. Hence it calls for a change in approach to day to day tasks from everyone in the team.

Challenge:

How can the team ensure the time lag involved in adjusting to the new phase of the project is minimized?

Possible solution:

• A formal kick off meeting that involves all the stake holders to define the roles and responsibilities of each team member clearly, at the earliest, definitely helps.
• Bringing in awareness in each team member about various aspects of the project like the new reporting structure (changes if any), SLA, roles, escalation process, etc.

• Handle project exits gracefully

The transition phase of a project is also the phase of the project where people move in and out of projects. This is one aspect of project planning which has always seemed to be very mysterious to me. One question that always haunts me is, “Why can’t we handle project exists gracefully?”

Challenge:

How can frictions involved in handling project exits be handled with grace?

Possible solution:

• Why does a friction arise in the first place? One reason that comes to my mind quite immediately is expectation mismatch. I sincerely feel that if there are enough avenues and channels created in the project, for every team member to reach out to their manager for discussing their short term and long term career plans, we can definitely minimize the friction involved in project exits and have smoother transitions.
• Project transitions can also be looked at as an opportunity in disguise. What kind of an opportunity am I talking about here? A project transition offers a great opportunity for the organization in general and a project in specific, to show great levels of maturity in terms of their approach to handle the talent pool, respecting the career aspirations of its people and show highest levels of professionalism in handling project transitions. Think about it.

• Who says only developments projects are challenging?

It’s quite a common notion that a development project is usually more hectic and challenging when compared to a maintenance project. While I agree with the hectic part of it, I feel a maintenance project can be equally challenging and sometimes even more.

Challenge:

The most challenging aspect of a maintenance project (I am specifically referring to the one where the maintenance team has access to the code base) is the ability of its team members to dig through other people’s code, understand the system end to end, and also enhance it. All this expected, with a caveat that it must not break the existing system.

Possible solutions:

• I sincerely feel that efforts should be made to equip team members with more than just good coding skills to work effectively in a maintenance project. This may call for providing programs that would benefit the team members to understand the project life cycles better and cope with them effectively.
• A maintenance project puts to test, one’s ability to do impact analysis before carrying out enhancements. It also demands quick learning abilities since not all project have the luxury of time to ramp up for support. Hence team members should be able to ramp up really quick.
• You would also agree that very rarely would a project have the luxury of retaining the entire development team in the maintenance phase too. Hence ensuring that all arrangements are made to equip new joinees with the necessary knowledge transfer is quintessential. This is also one area where we can explore for innovative techniques to achieve it.

• Drawing a road map for every team member is as important as drawing one for the project

As most of you would agree, project interviews are one of the widely used techniques for recruiting new team members for a project. A project interview is often carried out against a requirement, and for a designated role.

Challenges:

• As the time progresses and project grows in size, how can the project ensure that it can cater to the changing needs of its team members and to an extent the project itself?
• What can be done to make sure people are clearly informed of where their career is heading towards?

Possible solution:

• As the project grows or starts to hint any growth, it is very important for the team to assess the availability of new opportunities within the scope of the project and communicate the same to the team members. By doing so on a periodic basis, each team member gets a chance to make informed decisions when it comes to continuing with a project or to move on to a newer one. It works in the favor of both the project as well as the team member(s) in question.
• Most of the times when the organization wins a client and spends considerable time in knowing the customer and their business, they utilize the opportunity to draw a road map for the client so that it helps the client know how the organization can help them grow. I am always amazed why the same cannot be applied to a project. Look at this way. If a project has team members and they have spent considerable time in the project, why shouldn’t a project to draw a road map for such team members? I am sure it would help the team members, the project as well as the client since everyone is aware of the kind of roles or responsibilities them team members would taking up, going ahead. The project can also carve out a suitable space for them.

You may ask. What about a team member who is recruited for a short term requirement? How can a project chalk a road map for such team members?

I think it can be addressed in the following ways:

• I understand that it is practically impossible for projects to draw a career road map for such a team member within the space of the project. But it would not be a bad idea to discuss and understand their career aspirations since any such matching opportunity found in future can always be offered to the team member.
• Another way to address this issue is to avoid short term recruits (I know I am deviating from reality here) for any project, purely in the interest of both the project and the team members. A project team must plan such recruits only if gets really inevitable.

 P.S. In the end I feel this phase provides a great learning opportunity to everyone associated with the transition phase. It’s just that we must be open to learning from such experiences and works towards smoother project transitions.

Ways to implement Singleton Design Patten in Java

Of late, I have been going through Effective Java by Joshua Bloch and I must say, it’s one book every java developer must read. Josh has collated 78 best practices of java in this wonderful book. What I really appreciate about this book is the succintness and no-nonsense way Josh puts forth each of his learning in front of the readers.

There is an item which discusses about techniques to enforce singleton design pattern in java. I have illustrated below a few techniques to achieve the same.

 Technique 1: The “Eager instantiation” approach

1. Declare a class with a public static final field and intialize with a new instance of the class which is intended to be made singleton.
2. Declare a private constructor to limit clients from direct instantiation of the class.
3. All clients of this class will get an instance of the class using the public static final field.

Here’s how the singleton implementation would look like:

package com.corejava.examples.singletonimpl;

/**
 * Implementation of singleton design pattern – Technique 1
 *
 */
public class SingleInstance {
// Expose the instance of the singleton class as a public static final field
// of the class.

public static final SingleInstance SINGLE_INSTANCE = new SingleInstance();

private SingleInstance() {
// To prevent direct instantiation by clients
}

public void methodA() {

}

public void methodB() {

}

// … Rest of the methods of the singleton class go here

}

Advantges of this approach:

• Fairly simple and straight forward to implement.

Disadvantages of this approach:

• Creates an instance irrespective of whether or not the clients need an instance of this class.
• Violates encapsulation since the clients would be aware of the internals of the class.
• It makes code less flexible to design changes if you decide to move away from the singleton restriction in future since it brings in code change both at client side as well as the singleton class.
• Susceptible to attacks by reflection.

 Technique 2: The “Lazy instantiation” approach

1. Declare a class with a private static field.
2. Expose a synchronized static factory method to return an instance of the class (instantiate only if requested by a client)

Here’s the implementation for the same:

package com.corejava.examples.singletonimpl;

/**
* Implementation of singleton design pattern – Technique 2
*
*/
public class SingleInstance {

private static SingleInstance SINGLE_INSTANCE;

private SingleInstance() {
// To prevent direct instantiation by clients
}

public static synchronized SingleInstance getInstance() {
// Instantiate on a need basis and return the same instance for all
// subsequent calls.

if (SINGLE_INSTANCE == null) {
    SINGLE_INSTANCE = new SingleInstance();
}
return SINGLE_INSTANCE;
} 

public void methodA() {

}

public void methodB() {

}

// … Rest of the methods of the singleton class go here

}

Advantages of this approach:

1. Lazy instantiation of the singleton class.
2. Promotes encapsulation by hiding the internals of the class from the clients.
3. Gives flexibililty to move to a non-singleton approach without any code change at the client end since all clients access the instance via a common public method.

Disadvantages of this approach:

1. Susceptible to attacks by reflection.
2. Additional code required. (Not much of a disadvantage)

Technique 3: The Enum approach

package com.corejava.examples.singletonimpl;

/**
 * Implementation of singleton design pattern – Technique 3
 *
 */
public enum SingleInstance {

//Declare the enum constant

SINGLETON_INSTANCE;

public void methodA() {

}

public void methodB() {

}

// … Rest of the methods of the ENUM go here

}

Advantages of this approach:

1. Enums are singleton by default.
2. Every enum impliciltly extends from java.lang.Enum which implements Serializable interface. Hence enums provide an implicit serialization mechanism. Thus any even after serialization and deserialization of an enum class, the enum instance obtained is same as the one before serialization.

Disadvantages of this approach:

1. Enums are not extensible. (They were not meant for extension. Refer the sun microsystem java docs for enums for more info. However you may emulate multiple inheritance with enums by implementing multiple interfaces).

Hope the techniques mentioned above help to understand the merits and de-merits of each approach while implmenting the singleton design pattern in java.

Swap 2 numbers in java without using a temporary variable

I had tried out a few approaches while programming in C. A friend of mine happened to ask me the same. So thought of posting possible approaches here..

/**
 *  Program to swap 2 numbers in java without using a temporary variable
 */
package com.corejava.examples.pkg2;

public class SwapValues {

 public static void main(String[] args) {
  swapValByAddSub(2, -3);
  swapValByMulDiv(2, 5);// Fails when one or both the value(s) is 0
  swapValByXor(7, 8);
 }

 private static void swapValByAddSub(int a, int b) {
  System.out.println(“[swapValByAddSub] Before swapping: Value of A: [ "
    + a + " ] and Value of B: [ " + b + " ]“);
  // Use the add subtract operations to swap values
  a = a + b;
  b = a – b;
  a = a – b;
  System.out.println(“[swapValByAddSub] After swapping: Value of A: [ "
    + a + " ] and Value of B: [ " + b + " ]“);
 }

 private static void swapValByXor(int a, int b) {
  System.out.println(“[swapValByXor] Before swapping: Value of A: [ " + a
    + " ] and Value of B: [ " + b + " ]“);
  // Use the bitwise EX-OR operations
  a = a ^ b;
  b = b ^ a;
  a = a ^ b;
  System.out.println(“[swapValByXor] After swapping: Value of A: [ " + a
    + " ] and Value of B: [ " + b + " ]“);
 }

 private static void swapValByMulDiv(int a, int b) {
  System.out.println(“[swapValByMulDiv] Before swapping: Value of A: [ "
    + a + " ] and Value of B: [ " + b + " ]“);
  // Use the multiply divide operations to swap values
  a = a * b;
  b = a / b;
  a = a / b;
  System.out.println(“[swapValByMulDiv] After swapping: Value of A: [ "
    + a + " ] and Value of B: [ " + b + " ]“);
 }

}

The 2Cs of OO world – Cohesion and Coupling

Cohesion and Coupling – Look for the definition here and here …

Now that you have gone through a bit about Cohesion and Coupling in OO programming, I would like to share with you my own experience of identfying cohesiveness and coupling while you are actually out there implementing a java appplication. These will provide you pointers to figure out if you have violated either or both of the design principles.

Here’s a checklist for you of figure out if you have violated Cohesion:

1. Are you finding it hard to come out with a meaningful name for an interface or a class, that describes it completely and correctly?
2. Are you having problems coming out with a meaningful documentation of what each method in a class is doing or even worst, a class in question is intended to do? In others words, is the responsibility of a class well defined?
3. Is any method of your class doing more than what it is supposed to do?
4. Are the methods in a class functioning together as units to serve the overall purpose of the class in which they are declared?

 Here’s a checklist for you of figure out if you have violated Coupling:

1. Does one class of your application know more than it should about another class?
2. Are you passing data as parameters into the methods of your classes, which is more than what they require?
3. Are you finding it difficult to unit test methods of your classes?
4. Is a small change to one of the methods of your classes, impacting a lot of its clients?
5. Are the clients using the service rendered by a class through direct invocation of a service implementation or through an interface?

If you have found yourself answering in affirmitive most of the times, you have undoubtedly broken either  both of the above mentioned design principle in you application and should certainly revisit them to correct the same. I hope this checklist helps to make your code more maintainable.

I feel that the most simplest of all the ways to be sure whether or not you have broken a design principle or not, is to revisit the java docs of your APIs. Does it convey in clearest possible terms the intent behind your classes and its methods? If not, you must re-think your design.

As far as possible it is advisable to keep your classes “highly cohesive” and “loosely coupled”. In my view interface based programming is an excellent way of promoting ”cohesiveness” and ”loose coupling” (if defined diligently) between service provider(s) and  client(s).

P.S. Let me know if you have some more points to share.

Things to watch out for in a development project

I am almost done with the development phase of my project and what a learning it’s been so far! I am eager to share with you all what I observed during the course of the project. The following are some of the things to watch out for in a development project.

Knowing your team is as important as knowing your customer:

Why do I say this? Nine out of ten times, most development projects are executed against tight deadlines and hence time (which directly impacts the cost of execution of a project, more so if it is a fixed price project. You can’t afford to bleed too long, if you slip too much.) becomes a differentiating factor in deciding the fate of a project. When you are on a development project, it is extremely important to know your team very well. It’s more like playing a 20:20 match. You got to make the most out of what you have; both in terms of time as well as resources. This can only be done, if you know the strengths and weaknesses of each your team members really well. Once you know your team pretty well, you can etch out an effective game plan to tackle the project by utilizing every team member of your project to the fullest.

No matter how great plan A might look, always have a plan B:

They say, “Failing to plan is planning to fail”. Planning is undoubtedly the most important thing for the success of any project. But since software development is an iterative process, not everything can be planned in advance. It really helps to keep re-visiting the planning aspect of the project regularly and make suitable modifications to it from time to time. Why is plan B so important? Well, nothing (or rather no one) is infallible.  Things can really go out of schedule due to various reasons and might demand periodic interventions to repair the slippage in schedules. In other words, watch out for incremental slippages and act soon to make up for them. Schedule keeping is very important if you are to taste success even remotely in a development project.

Avoid re-work, design well:

Design phase is probably the most important phase of any project. It requires utmost attention and it is absolutely fine to spend a little bit more time here than to jump start development. Why do I say this? A lot of times, it so happens that under the pressure of meeting the deadlines of a project, people are forced to jump start development while the design is still underway. For me it is as good as asking the soldiers on the frontier to start the battle while the general is still preparing his final draft of the war strategy!!! It is very important to understand that every single day invested in to the design phase, can save at least 2 to 3 days (at times even more) of development effort. Imagine those Nth minute changes to your database tables or a major design flaw discovered during the later phase of a project.  It can cost your fortunes. So spend enough time here. You will never regret it!!

Think before you code:

This is one solid piece of advice our tech lead gave us when we were just heading towards the beginning of the coding phase. He put it in a way that ensured that each one of us not only understood it but also implemented it. He shot a mail to all of us which had a quote from Abraham Lincoln, “If I had 8 hours to chop a tree, I would rather spend 6 hours sharpening my axe.” He was spot on! I strongly believe that if one spends considerable time into thinking exactly what needs to be coded, the actual time required to code is very minimal.

House keeping job isn’t necessarily for the maintenance team :

House keeping job and that too in a development project!! You must be joking!! Well, I am not. When I say house keeping job, I meant tasks like ensuring all the team members adhere to the process set up in a project like coding standards, usage of project specific templates, documentation etc. I also add one more task to the house keeping category, which I feel, is often overlooked. How many teams have a plan in place to educate new joiners of a project and make them understand the processes and standards of the project? In other words, how many projects have the bandwidth to accommodate the luxury to educate new joiners? You may ask, “What’s the big deal?” Well, it really is. It often happens that due to time crunch, people who join in the middle of a project might not have enough time on their hands to get acquainted with the processes of a project. When such a thing happens, slowly but steadily deviations in the project starts to creep in. It might take various forms, like non conformation to coding standards, gaps in requirement understanding, etc. All the effort put in by the project from the beginning to adhere to a specific process might all go for a toss. Is it all worth it? Think about it.

Innovation = Being wiser than what you were yesterday:

Many a times we hear a lot about innovation and how it must be an integral part of a project and so on and so forth. How many times does it make sense to you? Well to me, innovation is nothing more than being wiser than what I was yesterday! At the end of the day innovation is doing things in a way that is better than the way it was done yesterday. If you are vigiliant enough, you will find umpteen opportunities of innvoation in your day to day life ranging from how you schedule your time to how you repsond to a problematic situation. Think about it. Innovation need not necessarily be always path breaking. It can be just simple things done in a different way.

A tribute to unmaintainable code

Words of caution: All views expressed in this article are purely mine (except for the quote below and you know whose it is) and surely does not represent those of the organization I work with. I am so tongue in the cheek, when it comes these disclaimers thing, is it not?

“If builders built buildings the way programmers write programs, then the first woodpecker that came along would destroy civilization.”
~ Weinberg’s Second Law

This post draws its inspiration from those night mares I had debugging or maintaining what I call a ‘filthy piece of code’. A kind of code that no developer would like to take the ownership of. Even though it is a pain in the ass to maintain such a code, it teaches you a lot. Most importantly, how not to develop a piece of code. Trust me it is really important at times to know what not to do, when there is so much to do!!

I have had the privilege to be a part of a project through its hectic development phase (the one where you survive on cup noodles after sun set and sandwiches after sun rise). Co-incidentally, I also happened to be a part of the maintenance phase of the same project. Since then it has been kind of love-hate relationship with both of them. The loving part being mostly the application development phase and the hating part being mostly the application maintenance phase of it, although both of them are tightly coupled!

Having been right in the middle of it, I feel the following is a subset of the reasons that can be attributed to unmaintainable codes that exist across the IT industry.

1. Project deadlines – Ask any developer who has been through the development phase of a project and I am sure 90% of them will surely attribute this unmaintainable code thing to project deadlines. I mean dude what would happen if you wish to deliver a baby before 9 months? You get it right? I feel most of the times a developer commits mistake(s) (or rather unforgivable errors) because people are so very bogged down by dates. I sometimes feel, the pressure of meeting deadlines introduces a lot of dead lines of code into an application.
2. Not thinking of code maintainability – As long as you don’t forget that there would be a team which would be maintaining your code (which might very well include you as well), I am sure you would do well as a programmer. A lot of times, in the middle of hectic project schedules, developers hardly enjoy the luxury to think of the maintenance team. So the question of adopting and implementing best coding practices remains for ever, in their to-do list or their new year resolution list!
3. Mistaking Ctrl+ C and Ctrl+ V to code re-usability – As long you are not one of those who subscribes to this misconception, you should really think twice before you duplicate a piece of code. I mean Ctrl + C and Ctrl + V are better used else where. You would rather be happy not including programming in the list of their usages!!
4. Ignoring the basics – If you are into Java/J2ee programming, you would know that it’s an ocean. I mean there is just too much information out there. Most of which may not even be correct. Every single day you would find so many newer frameworks getting introduced and each claiming to solve some or the other problem. But amidst all this what does not change is the basics of the programming language. So if you wish to write maintainable code, the first step towards achieving your mission would be strengthen your basics.
5. Not adhering to best practices – Adhering to best practices is so much like the Lakshman Rekha for Sita in Ramayan. You know that you should adhere to it, but end up not doing so. What adds to the problem? The fact that no 2 developers think the same way, makes thing worse as code passes from the hands of one developer to another. Since implementation of a solution is merely a function of the number of ways you know to solve a problem, a large part of how to code a functionality still lies at the mercy of a developer. Hence the only fool proof method to writing maintainable piece of code is by adhering to best practices of a programming language, as far as possible! Then may be you stand a chance, who knows?

P.S. At the end of the day I feel programming is more of an art. Everyone has his/her own style. But one thing that remains common is the importance to know your problem well and understand it thoroughly, even before you attempt to solve it.

Happy programming:)

Hello world!

Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!