Archive for April, 2009

Ten Commandments for Developers

April 19, 2009

Looking at the various projects that get into problems while execution, though management plays a big role in ensuring the success, I feel that the developers also play a significant role. It has to be made clear at the beginning of the project to the developers about the expectations that each one will play in the project. Though their specific role will change from one developer to the other, there are the Ten Commandments that need to be followed by all developers to guarantee good quality product being developed by the team. What are they?

Knowledge – the developers need to have the knowledge of the technologies concerned in the project. They cannot get back to the Manager saying that they are not aware of any specific language and thus they wouldn’t be able to do the job assigned. Once they are into the project, it is their duty to learn all the technologies involved in the project and be ready for the tasks assigned by the Manager. For example, saying that one would work only on the UI aspects of a web application and not the server-side is not a good idea. One should be ready to work on all tiers of the application.

Thoroughness – the developers have to be thorough in their work product. They have to take care that they analyze each and every piece of work that has been created by them and ensure that it matches the expectations of the product both in terms of conformance as well as quality. Finishing only part of the features expected in the project is not something that is expected from them.

Learning – Developers have to learn from each project. Otherwise, there is nothing called as experience. A developer who has worked on 5 projects can be counted as experienced only if he has learnt from the mistakes he has committed in each of these projects. Otherwise, it is as similar as having worked five times on the same project. Developers learn more than their mistakes than their successful code.

Discipline – Once they realize the various areas to be taken care, the developers have to inculcate the discipline in their work so that they don’t introduce any defects in their code. Once standards are set in a project and the Architects lay down the blueprints, the developers have to be disciplined enough to follow the same. Time is wasted when developers tend to write the code in their own unique manner and then tend to re-factor it in the way it is expected.

Let go of ego – the developers get into a rut sometimes, while working on a project. They get stuck on some specific issue – they spend a lot of time, without reaching out to other developers or their seniors. Why? They feel that they would be able to fix the issue themselves. Their ego comes in the way. It might appear that they are deficient in the technologies concerned and will reduce their standing in the eyes of other project members. Who gets affected in the process? The project. Let us all agree – nobody is perfect.

Confidence – Developers should be confident of their code (if they have followed all the best practices mentioned earlier) and should be able to go to any lengths to defend it against any reviews from the Customer. Obviously, there is a fine line between confidence and arrogance. If the developers have taken care of the basics, they should be confident about their output.

Estimation – You might feel why estimation is required for developers. Isn’t it not for the senior members of the project? No. When the project is in full flow, the action takes place at the developer’s end. When they are asked how long it will take for them to complete their tasks, the answer is not thought through clearly. They try to make the Manager happy by giving an estimate that looks good on paper but may not be actually realistic.

Testing – Yes, you heard it right. Developers think that it is their birthright to develop code (with defects) and it is the duty of the testers to find defects. The developers don’t do a self-review with their code and try to see how their code can be broken, if possible. If they try to plug the holes themselves, they wouldn’t have many issues cropping up in the latter phases of the project.

Big Picture – Developers don’t get the big picture in a project most of the times. They tend to concentrate on their module or class that they are working on. While this is good, it doesn’t give them the overall direction that the project is trying to undertake. It is always a good idea for them to reach out to the Senior folks in the project and find out why they are doing things in the way they are doing it.

Enjoy the project – Finally, one more point. It is a fact that no project will ever sail smoothly. There will be ups and downs in the project (very rare scenarios where projects will have a perfect journey). The developers have to understand and enjoy the various activities in the project – they should never get frustrated on the developments. This will ultimately show up as defects in the code.

These are very important points that all developers have to keep in mind. This will ensure that the project delivery becomes smoother and late nights or weekend workings are not necessary.


%d bloggers like this: