Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles / All-Topics

19 practical points to be remembered while working on a project/software-company

3.18/5 (63 votes)
8 Oct 2008CPOL4 min read 2  
Some useful practical points to be remembered while working on a project/software-company.

Introduction

This article will talk about some important points we should remember while working with tight deadline projects. I am sure everyone has some or other important points to share about working in software companies and projects. Do put your points here and I will consolidate and make a nice list, which I am sure will help the software professional community.

I have been writing and recording a lot of architecture related videos on Design Patterns, UML, estimation, and C# projects.

There is life outside projects….your life and your family. Love your work but not your project or the company. Many developers, after a certain amount of time, become possessive about the project and the company. Try to come on time and go on time. That way you do not get saturated, and will work on the project for a longer time and effectively.

Do not try be a hero in the project. Because heroes have to go through all the hardships. Believe in equal load distribution which is not only good for the project but also for you in the long run.

Every project has parasite developers. In short, every project has developers who constantly take help from others thus bringing down productivity. Yes, it is possible that those are your friends, but remember one thing: do not give fish to the needy, teach them how to fish. If you are a project manager, you should analyze those kinds of developers and ask for replacement, and if you are a developer, avoid doing their work from start to finish. Yes, give them hints, but do not code for them.

Do not make projects your learning ground. Customers pay heavily for making software, so do not make it a learning ground. In many projects, developers try to implement new technologies in the middle of the project just by hearing about jargons.

Do not treat your project people as resources. Project managers have this habit of thinking everyone as a resource. That is bookish thinking. Anyone working in a project is finally a human with emotions. The moment you consider them as a resource, they will consider you a resource as well.

Try to freeze your requirements before the start of the project. In practical scenarios, it is very difficult to control the end customer. But if you can at least control the changes, that will make the project more comfortable. The best way to control changes is by taking official sign offs or non-official sign offs from the end customer.

Test, test, and test. That’s the key to success for any software project.

Do not hide your defects. Developers are the best guys who know where the code will crash. Do not hide them, analyze and fix them. Do not cheat and leave them unattended till it goes to the client.

Avoid ego issues during projects. Many times in projects, developers and managers get stuck up with ego issues. Sometimes moving back makes the project move further.

Tackle bigger problems in the project first. The best way to complete any project is to start those screens which are used by the customer more often. For instance, every project has not so frequently used masters, code them later and start the transaction screens first. Many times, developers end up doing the nitty gritty work and forget the bigger parts of the project.

Do not talk about stars. Every project starts talking about stars but later end up somewhere else. Developers talk about concept of OOPs, full database normalization, Design Patterns, etc. These fundamentals are important but these should not end up as just jargons. Sometimes practical deadlines make it impossible to implement these features. Keep yourself flexible and compromise on quality when you have deadlines…..believe me, it is not a sin if the customer is giving you unreasonable deadlines.

Maintaining the right project hierarchy is very important, i.e., the A model. In A model, you have a senior person at the top, a project manager, a team leader, senior developers, and then juniors. The right proportion of people from each grade is important. On any level, if you have too much concentration, you will have ego issues and promotion issues.

Make yourself visible. If you think you have done something good, show it, advertise it, make it visible. This will help you during your assessment.

Avoid getting into project politics. Peace of mind is the most important thing. Getting into egos and politics will only complicate things.

If you are working on maintenance projects, upgrade yourself from time to time.

In case you are maintaining some other developer's code, do not criticize the code. Who knows in what circumstances the project was made.

If you are a project manager, do not make it a compulsory rule that you will never touch code. Remember, juniors respect their seniors if they sit with them during development and understand their difficulties.

If any resource is working on a project for more than a year, his performance comes down. Prepare a proper KT plan and bring in new resources and roll the old resources off for some better prospects.

Avoid unnecessary meetings.

For further reading do watch the below interview preparation and step by step video series.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)