Common excuses a Developer makes when a feature doesn't work [And how to avoid them in the future]

Tuesday, 29 October 2013

Common excuses a Developer makes when a feature doesn't work [And how to avoid them in the future]

I always feel that Developers should have an attitude for development, which I have detailed in the blog post Attitudes of a Great Software Developer. But generally when it comes to issues, a lot of developers make excuses. As long they are genuine, it is not a matter of concern however if it is really an Excuse, then it is a cause for concern for the entire team. I am guilty of a few of those myself however when I saw the big picture, I rectified those and understood why people make those excuses and how we can avoid them in the future. I am detailing a few in my below post.

1. It works fine in my machine

Come on guys, this is the number one excuse that developers give. We often have a feeling that testers or the customers have a magical computer which injects bugs into our code. But that is far from true.

The only way to avoid this excuse is to be aware of the environments that are used for development, testing and production. By being aware of those, the first thing you would probably ask is, what sort of configuration/environment it is and get more details about the issue and check if it is really a valid bug. Another way to avoid this is to have a Continuous Integration environment, where with each and every code check-in, code is compiled and deployed in some test machines.

Image courtesy: cheatcc.com

2. Do you have the latest build?

This is another excuse that developers give. Not having the latest build to test or testing a wrong build can sometimes be the reason for such excuses. However it may not be the case always.

The only way to avoid this is to have a process in place that will verify if the build that the testers are testing is a valid one and is the latest. One way of doing this is to have a continuous integration process wherein code gets automatically built and deployed on test machines automatically. That way the process makes sure that the build is the latest build. Another way to ensure this is to verify the build numbers that is currently being tested or deployed, if this matches with the devs, then you can be sure that this is not the issue.

3. Must be a configuration issue.

If you told me this, I would reply "Oh yeah. May be it is a configuration issue. So can you point out what exact configuration changes that I need to do make it work?" :) and it's likely that you also would ask a similar question if faced with this situation. So as you can see, people need specific answers not generic ones.

Best way to avoid this to have all the configuration related parameters defined in a separate configuration file, and have dynamic values written in some log file so that it can be referred in case of any confusions. By having it in a documented format at runtime, chances of errors are minimal and even if the issue is due to a configuration issue, we can easily find that out.

4. Please raise a defect, I will check it

From my point of view, raising a defect without even confirming whether it is a defect or not, sounds trouble to me. The trouble can be either in the process that is being followed or the coordination between the dev and the testers. Typically Dev and testers should join hands in case testers are not able to really drill it down if it is a defect or not.

One way to avoid this is to have a good team morale and collaboration between the developers and the testers. In that way, they will discuss and try to figure out whether it is actually a defect.

5. Try restarting your machine :P

This is one of the killer excuses that the Developers make. I have also done this. Yeah, it does happen with Microsoft related technologies for some reason (I used .net predominantly in my previous projects) and very rare occasions this excellent and well thought out, scientifically proven method works with Windows :P, but most of the times it is false.

One way to avoid this to be again aware of the environment and the functionality and the architecture and the code design. By being aware we can identify whether it is actually an issue or not.

6. I am not sure why it isn't working. Let me check it

I hate this excuse when it comes from a developer. If as a developer, you are not sure as to why a particular thing is not working, then either you have not understood the functionality correctly or you are not aware of the code design

One way to avoid this to have a mental map of the modules and once the issue is told, the dev needs to analyze it immediately and find out where the likely problem would be. Not being sure of where the problem might occur is a cause for concern either due to badly designed code, poor code or lack of understanding of the functionality or the modules.

7. It worked fine just 5 minutes back

Wow. How sweet. I think you have put in a time bomb in there that made it not to work after 5 minutes.

One way to avoid this is to be aware of the fact that the code doesn't change with time unless it is time specific code. So any other functionality will not have such variable behaviors.

8. I don't think there's fault with my code

This is another answer I generally wouldn't give if I am faced with the situation. I believe there is nothing called my code especially in a team environment. I would rather say maybe something is wrong with this so and so module. This is trying to find a person to blame and this is definitely not in the best interest of the team morale.

One way to avoid this is to embrace team culture and also rotate the developers among different modules so that no one takes ownership of a particular module and hence everyone knows about the entire code base.

What other excuses do developers make and how to avoid them in the future? Please shoot out your comments below. If you found this post useful, please share it with your circles. You can stay updated with the latest blog post by simply submitting your email id to the right in the section "Get Updates by Email"

Free E-Book - Programmer's Motivation for Beginners

About the Author

Rajaraman Raghuraman has 8+ years of experience in the Information Technology industry focusing on Product Development, R&D, Test Data Management and Automation Testing. He has architected a TDM product from scratch and currently leads the TDM Product Development team in an IT MNC. He is passionate about Agile Methodologies and is a huge fan of Product Development, Agile Development and Agile Testing. He blogs at AgileDevTest Blog. He is also an author of a free Ebook "Programmer's Motivation for Beginners". Connect with him on Google+