Top 10 excuses why techies don't give projects on time

1) Requirement Slippage: "What can I do, if the client does not stick to his requirements?" Any techie you come across must have either made this excuse or must have come across it. Many times, when the team members in a particular project are about to complete the project keeping the client requirements in mind, they are insisted to either make certain changes in the project or bring in some addition to it. Requirement slippage is a genuine problem faced by team members in a project but many times it becomes the easiest excuse for any techie if the project is delayed. This excuse is often validated by the organization and the team members can easily prove themselves impeccable.

2) Wrong Project estimation: Project estimation is usually given by a module leader who is not deeply associated with the project. He or she is the one who builds relationship between the client and the project team and integrates the module's findings into the broader project work. Usually when the project demands some more time to be delivered, the team members crib about the project not being estimated in an appropriate manner. At times, the requirement is underestimated, the time frame is not fixed in sync with the project and the entire project is not compatible with the engineers working on the project. This excuse has a broader dimension as any one part of the project estimation could become a reason for extending the time for project delivery.

3) Work Overload: Attrition is no big news in the IT industry. The software professionals deal with immense pressure in coding their programmes correctly. In such a case, when one team member resigns, the existing team members are overloaded with the pending work of the ex-employee. And in such a case, the priorities of the project team members change and this becomes another excuse for team members.

4) Infrastructural issues: Well if nothing works out, then this is the excuse which everyone resorts to. Blame it on the company's infrastructure. Indian IT infrastructure usually lacks with effective resources like availability of power and high bandwidth. So probably one could understand the frustration caused due to a technical snag. Each time there is an infrastructural slowdown, the efficiency of employees comes down.

5) Information does not get passed on, lack of understanding of processes: Communication of the project details seems to be another area for making an excuse. If the project is not delivered on time, the problem could be directed to the organizational processes. The discrepancy in understanding of a project requirement is one point which the techies pick on to make an excuse.

6) Health issues: This is the most common excuse which prevails in every sector. This is one area, where the employees can't be questioned further. It has been widely seen that many IT professionals take sick leaves on Mondays because they are reluctant to work on Mondays after a relaxed weekend.

7) Unplanned Holidays: Take the recent verdict on Ayodhya. The fear of the consequences of the judgement led all the IT companies work for only half a day. Most of the holidays are granted to the IT professionals due to bandhs at both national and state level. The major development to the project comes to a halt when an organisation remains closed for a day or half. And this is often a valid reason for the failure of delivery of project on time.

8) Lack of proper skill set in a team: The experienced team members often accountable to higher authorities blame it on the unavailability of skilled engineers in the project. The hiring of additional developers late in the software development cycle, after not meeting some deadline, is often the factor in delayed contributions from the newcomers as they take time to familiarise themselves with the project. This contributes to a great deal of time lost in coordinating their joining the group.

9) Poor planning or management: the role of project manager is not only to give the final word to the team members and to arrive at a particular timeline for the project. If the person taking on the role of project manager has poor planning and managerial skills, the team members could point this as a reason for the project fall over.

10) Quality control and documentation: The major problem of a late running project. Many engineers try to find an excuse for the sake of quality assurance. It is easy to get away with this excuse as the client is also willing to compromise with the deadline for the sake of quality.

Abstract Class vs Interface

Introduction:

There are lost of discussion on the internet about the Interface vs Abstract class. Also, as base class whether we have to use interface, abstract class or normal class.

I am trying to point out few considerations on which we can take decision about Interface vs Abstract class vs Class.

Abstract Class vs Interface

I am assuming you are having all the basic knowledge of abstract and interface keyword. I am just briefing the basics.

We can not make instance of Abstract Class as well as Interface.

Here are few differences in Abstract class and Interface as per the definition.

Abstract class can contain abstract methods, abstract property as well as other members (just like normal class).

Interface can only contain abstract methods, properties but we don’t need to put abstract and public keyword. All the methods and properties defined in Interface are by default public and abstract.

//Abstarct Class

public abstract class Vehicles

{

private int noOfWheel;

private string color;

public abstract string Engine

{

get;

set;

}

public abstract void Accelerator();

}

//Interface

public interface Vehicles

{

string Engine

{

get;

set;

}

void Accelerator();

}

We can see abstract class contains private members also we can put some methods with implementation also. But in case of interface only methods and properties allowed.

We use abstract class and Interface for the base class in our application.

This is all about the language defination. Now million doller question:

How can we take decision about when we have to use Interface and when Abstract Class.

Basicly abstact class is a abstract view of any realword entity and interface is more abstract one. When we thinking about the entity there are two things one is intention and one is implemntation. Intention means I know about the entity and also may have idea about its state as well as behaviour but don’t know about how its looks or works or may know partially. Implementation means actual state and behaviour of entity.

Enough theory lets take an example.

I am trying to make a Content Management System where content is a genralize form of article, reviews, blogs etc.

CONTENT

ARTICLE

BLOGS

REVIEW

So content is our base class now how we make a decision whether content class should be Abstract class, Interface or normal class.

First normal class vs other type (abstract and interface). If content is not a core entity of my application means as per the business logic if content is nothing in my application only Article, Blogs, Review are the core part of business logic then content class should not be a normal class because I’ll never make instance of that class. So if you will never make instance of base class then Abstract class and Interface are the more appropriate choice.

Second between Interface and Abstract Class.

CONTENT Publish ()

ARTICLE

BLOGS

REVIEW

As you can see content having behavior named “Publish”. If according to my business logic Publish having some default behavior which apply to all I’ll prefer content class as an Abstract class. If there is no default behavior for the “Publish” and every drive class makes their own implementation then there is no need to implement “Publish” behavior in the base case I’ll prefer Interface.

These are the in general idea of taking decision between abstract class, interface and normal class. But there is one catch. As we all know there is one constant in software that is “CHANGE”. If I made content class as Interface then it is difficult to make changes in base class because if I add new method or property in content interface then I have to implement new method in every drive class. These problems will over come if you are using abstract class for content class and new method is not an abstract type. So we can replace interface with abstract class except multiple inheritance.

CAN-DO and IS-A relationship is also define the deference between Interface and abstract class. As we already discuss Interface can be use for multiple inheritance for example we have another interface named “ICopy” which having behavior copy and every drive class have to implements its own implementation of Copy. If “Article” class drive from abstract class Content as well as ICopy then article “CAN-DO” copy also.

IS-A is for “generalization” and “specialization” means content is a generalize form of Article, Blogs, Review and Article, Blogs, Review are a specialize form of Content.

So, abstract class defines core identity. If we are thinking in term of speed then abstract is fast then interface because interface requires extra in-direction.

So as per my view Abstract class having upper-hand in compare to interface. Using interface having only advantage of multiple inheritance. If you don’t understand the things then don’t worry because it’s my mistake because I am not able to describe the topic.