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.