on 02 April 20
Here are 8 common excuses
1) I canâï¿½ï¿½t understand why?
Probably a very poor excuse from developers, if you are unsure of why a certain feature is not working, then either you have not understand the functionality correctly or you are not aware of the code design.
To prevent this from happening, you should have a mental map of the modules and once an issue is raised, the developer is able to assess the situation straightaway 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.
2) Darn, has to be a configuration issue
I think it could be a configuration issue. Well, the probable answer would be what exact configuration changes do I need to make it work? It seems people are getting immune to such excuses and seek much needed specific answers instead of generic ones.
Well guys, to avoid such an excuse you can have all your configuration related parameters defined in a separate configuration file, and have dynamic values written in some log file to be used a form of reference. 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, you can easily sort them out.
3) It seems to be working well in my machine!
This is one of the top excuses developers give. It seems that thereâï¿½ï¿½s some sort of a hidden agenda among testers or customers who have some special computer which injects bugs into our code. But that is far from true.
To prevent yourself from making this excuse, you should be aware of the environments that are used for development, testing and production. By doing so, you might want to ponder on what sort of configuration/environment it is and acquire more information about the issue and see if it is really an actual bug.
Another way to prevent this from happening is to have a Continuous Integration environment, where with each and every code check-in; the codes are deployed in some test machines.
4) Doesnâï¿½ï¿½t work? Maybe you can try restarting it! :)
Yet another popular excuse, funny thing is that Microsoft developers tend to make these excuses. And very seldom this brilliant and unproven method works with Windows.
To avoid this, you have to be 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.
5) Itâï¿½ï¿½s not my fault, thereâï¿½ï¿½s nothing wrong with my code
I highly recommend to not, never, and donâï¿½ï¿½t give this excuse especially if youâï¿½ï¿½re working in a team. I believe there is nothing called my code especially in a team based environment.
I would rather say maybe something is wrong with this so and so module. By giving such an excuse, you are deliberately throwing the blame to somebody other than yourself without even checking.
One way to such mishaps within your team is to 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.
6) But it was working fine just a while ago?!
Gosh! You must have smashed it with something to make it not work after 5 minutes!
One definite way to understand this is the fact that the code doesnâï¿½ï¿½t change with time unless it is a time specific code. So any other functionality will not have such variable behaviors.
7) Thereâï¿½ï¿½s a defect? Should I check it?
You know, itâï¿½ï¿½s problematic if you raise a defect without even confirming whether it is a defect or not, and that can be irksome. The problem can be either in the process that is being followed or the coordination between the dev and the testers. Typically Developes and testers should work together in case testers are not able to get to the bottom if it is a defect or not.
The best way to avoid this is to have close collaboration between the developers and the testers. In that way, they will discuss and try to figure out whether it is actually a defect.
8) Are you currently using the latest build?
Another popular excuse, do you have the latest build to test? Usually are reasons for such an excuse. However, you can prevent such excuses from a developer.
To avoid such an excuse, you should have a process in place that helps you to authenticate if the build that the testers are testing is a valid one and is indeed the latest. One way of doing this is to implement a continuous integration process wherein code gets automatically built and deployed on test machines automatically. By doing so, the process ensures your 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.
Apart from abovementioned excuses, here are other noteworthy common one liners you may have heard before.
Your browser must be caching the old content.
It's a browser compatibility issue.
Are you using Internet Explorer Web Browser?
It must be a hardware problem.
It must be a firewall issue
"Did you check for a virus on your system?"
"It's never done that before!."
It's a known bug with the programming language.
I haven't had any experience with that before
Oh, that was just a temporary fix
To conclude, as we struggle towards our programming journey, it seems setbacks happen time to time. But do note that the hard work we put in will eventually pay off with success. :)
This blog is listed under Development & Implementations Community
Share your perspective
Share your achievement or new finding or bring a new tech idea to life. Your IT community is waiting!