Monday 21 January 2008

Dirty programming versus clean programming

In my short development experience, I met developers who code like "pigs", that is, they violate all coding best practices (no matter they have time or not!). Most of the time, their argument to explain this, is that the time allocated for the task is too "short".

In all projects, we have time constraints. Does that mean, we should try to deliver things even if the work done behind is of a poor quality ? What is the degree of compromise between quality and delivery date ?

I personally think that in these cases, we should develop the most important modules of the project and inside these modules, we should deliver the most important functionalities, keeping in mind the quality requirements of the project.

For less important (less priority) functionalities, we should atleast try to put in place the code structure, that in future, will allow us to quicky and cleanly add the remaining functionalities.

In this process, we could use the Open-Closed principle, which says that a delivered software must not be modifiable but extensible: lets explain this. If you modify a delivered software, there is a risk of regression and side effects, for example, we could break existing functions of our software. But if our software is extensible, we can enrich it with new functionalities without touching to the existing ones.

2 comments:

Anonymous said...

Hopefully, you work in my company!

Anonymous said...

The Open-Closed principle is great. Very much aligning to the Agile Methodology. However, it works well when new functionalities need to be added, so we can easily extend the code. In my project, client request is to remove code... so i have no choice but to modify the software.. and yes.. it results in impacts to other functions.... Great article.

From: Vijendra -- Accenture