Monitoring the health of a development project

I have been thinking about this role for quite some time now. I have been on a couple of development projects and one thing that stood out in common was the lack of time invested in design review, code reviews on an ongoing basis, throughout the life cycle of the development project. Even if there were reviews, most of them cited the obvious which mostly revolved around good naming conventions, etc. But what I have been looking for is a review that could help me validate the choice of a design principle or say a strategy to solve a complex UI requirement. But unfortunately there hasn’t been much happening on this front.

The following are the reasons why I feel why there haven’t been enough reviews happening:

1. Too many meetings – This is probably the main culprit. I observed there are way too many meetings happening all the time and you would have all the leads attending one meeting or the other all the time. It leaves them with very little time in a day to focus on the “Actual Task” at hand.
2. Lead to Developer ratio – This is another major contributor for the lack quality reviews from leads. A good lead to developer ratio (Module lead) 1:3. Why this ratio? I feel that a module lead can devote his time towards 3 developers at the max and still be able to deliver as expected. Once this number exceeds, things begin to get a little bit out of control. A lead then has to start spending a lot more that required time with developers to clarify and addressing issues. This leaves him with little time to focus on his regular tasks like code reviews or low level design. Hence it is very important to maintain this ratio.
3. Process is a means of achieving the end result not the end itself – Let’s face it. Process is good. But it should always be adopted with a pinch of salt. If we bring in too may processes, it will only introduce too many levels for achieving something in a project. I am talking here about some process which has just been adopted because you wanna come out clean in some XYZ standards audit. Heck! it’s not gonna work. You may end up having followed all the processes but the end deliverable is not just what the customer wanted. It is more of a “means” to achieve results and not the “end result” in itself.
4. Dead lines – I had written it before too. Just re-iterating it here; Deadlines often introduce a lot of dead lines of code in a project. It is very important to keep a tab on the time lines and make the most out of it. Hence the development team must get its due time. Reviews must happen on time and shouldn’t be a post harvest/project retrospection activity. Looming deadlines should never be a reason for postponing reviews.
5. Lack of demarcation of roles and responsibilities– A project must have a clear demarcation of roles and responsibilities. This is required for 2 things. Firstly, It sets the right expectation with the person discharging the responsibilities associated with the role. Secondly, it avoids unnecessary confusions and duplication of efforts in the team since everyone knows exactly what he/she is supposed to do and not to do. Sometimes it these little things like knowing exactly what to do that can work wonders for a team in a time crunch situation.

Due to the above, we find a lot of projects deviating from their normal course, without getting noticed. Can this be avoided? Can a project be saved from gradual derailment?

I think yes! What we need to do, is to introduce a role into the project, that would be of a dedicated reviewer.

Some of the salient responsibilities of this role could be:

1. Ensure that reviews are done on time and development team get good feedback on their implementations and designers on their designs.
2. The person assigned with this role, would be accountable for ensuring the reviews happening on time and not the execution of the end deliverable in itself.
3. The person is expected to be available at all times to provide feedback and flag deviations as soon he/she identifies it in the project. This would help teams to rectify inconsistencies as soon as they get introduced into the system, either in the design or implementation.
4. Facilitate the development team in identifying re-usable components as and when he/she discovers an opporunity.

After going through the above description of the role, you might get a feeling that the role is very much close to what a Technical Lead it supposed to do. Ain’t it? But I beg to differ with you here and here’s why.

A Technical Lead is not only accountable for giving a high level design but also is highly accountable to the actual deliverable. Hence his scope of work often spills over from just technical guidance to managerial aspects of the project. It would also get increasingly difficult to attend to the queries of the entire team.

Hence there is a need for a role whose sole responsibility is to monitor the progress of the development project. Give quality feedback and conduct “continous reviews” and ensure the project’s health is always green.

Null pointers in Java

Ask any developer who has dirtied his hands with java programming, even slightly, “What is the most common (and probably the most ugliest of all exceptions) exception that he/she has come across during development?” I swear it will the infamous Null Pointer Exception [api doc] in java.

The best way to avoid is to have suitable null checks [ever heard of defensive programming?] in you code so that you are sure your program does not spit null pointer exception.

A couple of days back when I was debugging a method in a program that used a custom utility method to check for “null” value of an object. It was a real eye opener for me for I never really thought that that utility method that check for a null value could fool me like that.

Here is what happened…

[MyTestVO.java]

public Class MyTestVO implements Serializable{

private String loginName;

private String password;

public MyTestVO(String loginName, String password){

this.loginName = loginName;

this.password = password;

}

@Override

public String toString(){

StringBuffer sb = new StringBuffer();

sb.append("Login Name: "this.loginName);

sb.append("password:"this.password);

return null;

}

}

[CustomUtils.java]

public Class CustomUtils{

public static boolean isEmpty(Object value){

if(value == null){

return true;

}

if( value instanceof String ){

if( value.length == 0 ){

return true;

}

}

if(value instanceof Collections){

if( value.isEmpty( ) ){

return true;

}

}

if( value instanceof Map ){

if( value.isEmpty( ) ){

return true;

}

}

else if (value.toString() == null){

return true;

}

}

[MyTestClass.java]

public Class MyTestClass{

public static void main(String args[]) {

MyTestVO myTestVO = new MyTestVO("Test_Login_Name","Test_Password");

if(CustomUtils.isEmpty(myTestVO)){

System.out.println("My TestVO is null");

}

else {

System.out.println("My TestVO is not null");

}

}

}

Output: My TestVO is null


The above is a close simulation of the problem [the actual one involved populating the VO from the values fetched from a DB and processed by the business layer method]. However the issue is not that. The isEmpty() method in the custom utility class returned true!!

In such cases you first shot would be check you DAO method where you fetch the data from a Data access layer and see if the method returned a correct value or is it returning null.

The next check would be at the service layer method which returns this value object. But in my case both of them see to be working perfectly fine. Then where was the problem?

It really took me sometime to figure out that the culprit is the overridden toString() method in my VO class which seemed to always return null. The custom utility class returned true if the toString() on the object returned null (for me it makes no sense to have this check since I am not interested to investigate if I can invoke a toString() on a null object or not, when the object reference itself is null. However a check on the length when value passed is a string makes sense to me).

I do agree that the toString() method should have been implemented more carefully but then where is the fun if your program runs in one shot (so much for my naivety) . But I felt the utility classes’s isEmpty() is no less a culprit:)

Phew! Gotta be really weary when performing null checks!

They are the first things to be tested even before you hit the compile button. Having said that, I myself have done it innumerable times only to have seen the infamous stack trace I recognize with ease:)

P.S. I came across this video where the author speaks of static null analysis and how static null analysis plug in with Eclipse IDE fails at some places. The author also cites the scenarios in which a null pointer exception can occur.

The pragmatic programmer – Andy Hunt and Dave Thomas

The Pragmatic Programmer

After reading some really positive reviews of this book, I finally placed an order of this book on flipkart.com. I got my copy in just 3 days. I was really looking forward to read this book since it had generated a lot of curiosity in me after reading the table of contents.

I must say that the book is must read for every programmer. The reason why I liked this book the most is the presentation of the content in a tone that is slightly different from a hardcore technical book. Both Andy and Dave have done a great job in compiling some of the best practices of programming. The authors also throw some light on what it takes to be a pragmatic programmer. You will find almost every tip useful in one or the other way. I must say that it is a total no-nonsense guide to becoming a programmer who does more than just coding.

My personal favorites in this book include a section that talks about the importance of communication between members that develop software. The authors recommend the following tips to help ensure the communication is really effective.

1. Know your audience

It is very important to know who your audience is while communicating something. As a developer we always have the tendency to get into the technicalities of an issue while communicating it to the clients or even other stake holder who may not necessarily be initiated to consume this information. Hence know your audience and sample the right information that needs to be communicated. E.g. If you are talking to a marketing team about a software they might be more interesting in knowing how the customer is benefitted by using a software than to know what are those coolest design patterns you managed to implement in the software.

To be more precise the author suggests remembering an acrostic WISDOM that best describes aspects to be kept in mind for successful communication:

1. What do you want them to learn?

2. What is their interest in what you’ve got to say?

3. How sophisticated are they?

4. How much detail do they want?

5. Whom do you want to own the information?

6. How can you motivate them to listen to you?

2.  Choose your moment

For a communication to be really effective what matters is not just what you say or even how you say, but also when you say. Let’s say that it’s Friday evening (say about 6:15 pm) and you get a brilliant idea. You decide to walk up to your manager, who has just got a call from his relatives asking him to rush to a hospital to see someone who isn’t keeping well.  What do you think you should do? Do you think it is right time to talk? Certainly this isn’t a great time to talk, no matter what. You may be having the best idea that can change things around, but if it is not presented at the right time, it is really ineffective. So be diligent of the timing of the communication and choose the right moment to present your ideas.

3. Choose your style

It is very important to choose a style for communication. It sets the right expectations from the audience. If someone is asking you for presenting something in just a paragraph and you are convinced that it can be done with no less than a single page, tell it up front. Since you form half of the transaction in any communication, it is very important to have a style for communication to set the right expectations from the audience.

4. Make it look good

If your ideas are really good why present them uninterestedly? Try to present your ideas in a neat and succinct manner by avoid common mistakes like typos and grammatical mistakes. Use the right formatting and word processing tools to better the presentation.

After awl, their are spelling miss steaks that the chequer can knot ketch. [You get it right?]

5. Involve your audience

We often find that the documents we produce end up being less important than the process we go through to produce them. If possible, involve your readers with early drafts of your document. Get their feedback, and pick their brains. You’ll build a good working relationship, and you’ll probably produce a better document in the process. Try this out. It works!!

6. Be a listener

Are you surprised to see this point here? Well it really is one of the most important aspects of any communication. There is one surest way to make people listen to you: Listen to them carefully when they speak! Try this out. Next time you have something really important to say and you approach the stake holders, allow them to speak. Listen to them carefully, even if you know all of what they are saying. Then present your ideas. I am sure you will be surprised to see how they lend their ears to your ideas/points.

7. Get back to people

“I’ll get back to you”. This is probably the most widely abused phrase of all times. When you say this someone, please be sure you really mean it. Don’t just say it because it’s hip hop or a cool phrase. If you get back to people who have contacted you either on your mailbox or voice mail, you are not only responding, but showing due respect to the person at the other end. It actually speaks volumes about you as an individual. Always get back to people, else tell them up front. The last thing people want is to be kept guessing!!!

I hope the above points would help you communicate better in you workplace and significantly impact all your communications.

The other topics that have deeply kept me interested are:

1. The concept of orthogonality in software development (AOP based programming stems from this concept)
2. DRY principle [Evils of duplication]
3. Testability of a code
4. Re-factoring
5. The requirements trap

I sincerely recommend this book to all those developers who are keen to learn and pick up some very good practices that can help you better yourself as a programmer. This book is worth every penny and you will not regret it.

A snapshot of what constitutes a good design

I found this image here and felt that it captured almost everything I wished to talk about a good OO design and how to achieve it.

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:)