Friday, April 02, 2010

Who is to be blamed For Writing Crappy Code?

For any typical development of any feature, the following is the general process.

  • High level Design
  • Rough Implementation of the main line scenario
  • Manual Testing of the main line scenario
  • Making the code clean
  • Writing automation testcases for the main line scenario
  • Rough Implementation of all the other scenarios
  • Manual Testing of all the other scenarios
  • Making the code clean
  • Writing automation testcases for all the other scenarios.
  • Verifying the entire functionality and code for performance, security, integration and functionality miss.
  • Implementation of the above
  • Manual testing
  • Automation testing

For any reasonably big feature this is the general process. Few steps may take less time and few may take more time. But, all are important. If a developer gives an estimate of 10 days for any functionality, then it is possible for the developer to declare code complete after the first 3 steps and may be in 2-3 days. But, that will have bugs, misses in the functionality, performance and security problems etc.

Let's take a hypothetical situation of a developer and a hypothetical story.

The developer is given only 25% of the time to finish the functionality. So, he could do only the first three steps in the above process, and delivered the code. The test team identified few bugs in that in functionality, performance and security. Even to fix the bugs, the management decided the time, and developer was not asked for the estimations. So, the developer had time just to fix the given bug and nothing else.

Since the developer knew that, the product is not in a clean state, and he suggested architectural changes to improve the product. But, nobody listened to him. The management has changed, and even the new management did not approve of changing the architecture of the product.

Whenever the developer is working on any functionality, he used to spend one or two hours extra, and started cleaning up existing code. Once the developer got plenty of time, since nothing was assigned to him. He started cleaning up few main classes. Other team members saw this and raised this issue in a meeting. All non-developers unanimously decided that, the developer should not change the code like that. If he wants to change anything in the code, he has to write a detailed design doc first, and present to everyone in the team. Once everyone approves that, then he can go ahead with the implementation. Till then, he should not change any thing in the code. The developer said, there is nothing major he is changing. Since the code is crappy, he is looking at each method, and cleaning it without modifying any behaviour. There is nothing to write in a design doc for that. But, nobody agreed to his proposal. The developer had to sit idle for few more days, because nothing was assigned to him, and he was not allowed to clean up the code.

After few months, one serious performance issue came up. Another developer looked at the code and found the bottleneck method. That code is very crappy. He rewritten that method in two hours, and the performance is improved by 10 times. The new developer asked the entire team, who wrote that method originally. It was written by the first developer.

The developer who originally wrote that code has to be blamed for writing that much crappy code. It does not matter what were the reasons behind that. In the source control, his name is against that version of the code. So, he only has to be blamed for that. This should highlight in the review process. This much crappy code is not expected from a person, who has so many years of experience.

No comments:

Post a Comment