Software Development

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
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.
 

Rajaraman Raghuraman

Rajaraman Raghuraman is a highly passionate software craftsman with 8+ years of experience in the IT industry. He is also the owner of AgileDevTest Blog (http://agiledevtest.blogspot.com) and author of an Ebook "Programmer's Motivation for Beginners" which is available at http://programmersmotivation.com.
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

10 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Thomas
Thomas
10 years ago

“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” I’m working on at least three projects at the same time, everyone with other design and technology and should immediatly know where the problem is from a quick bug description? Sure. “Let me check it” says nothing more then “I need some… Read more »

Christian
Christian
10 years ago

Thats a pretty lame article. It just shows the author doesn’t understand software development that well. Considering each of these phrases as an “excuse” is plain wrong. Esp #6 – i fully agree with what Thomas wrote below. Maybe the author has only worked with software which was written by a single developer. But software written in a 20 man team can become difficult and nobody can expect that you have every place in code in mind. Sometimes problems are cause by in example multithreading issues which are hard to spot. #2 – sure please use the latest build because… Read more »

Rajaraman Raghuraman
10 years ago
Reply to  Christian

Hi Christian, Thanks for commenting. I appreciate your genuine feedback that most of them may not be excuses. That is why I started the article with the following lines “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 perfectly understand that each and every excuse that I had mentioned can also be very genuine or can’t be treated as an excuse and we don’t have… Read more »

Iacopo
Iacopo
10 years ago

I think you’re not getting the point. Most of the ‘excuses’ you cite are indeed other things. 2 – You should always test the relevant build: it’s not an excuse, it is a rhetorical question since a tester that is not testing against the relevant build is not doing his/her job. 3 – Have you read the manual? If there’s a good manual AND the errors are reported sensibly, a tester should be able to configure the system and avoid a generic ‘configuration error’. Did you mess with the configuration files? 6 – How on Earth can you blame someone… Read more »

Mike
Mike
10 years ago

Nice response lacopo

Matthew
Matthew
10 years ago

6 – Guess you only work on “hello world” softwares :p.

itoctopus (@itoctopus)
10 years ago

These excuses are standard – especially the first one (it works on my machine). The thing is – even professional developers use these excuses, but they use it slightly differently. Here’s an example: “That’s odd – it works on my machine. Let me try to debug what’s going on on your end”. By the way, in 99.99% of the times, when a developer says that something is working on his machine, he’s not lying. Our domain is extremely vast and it’s generally really hard to locate the problem when the person with the problem is somewhere thousands of miles away.… Read more »

Nanni
Nanni
10 years ago

Clear the cache!!!!!!!!!!!!!!!!!!!!!!!!!! :)

deadhorse
deadhorse
9 years ago

Probably the best display of ignorance I’ve ever seen right here. -. Build does matter, I mean seriously.. what? -. Configuration is many times the reason. -. Raise a defect is also valid, a dev rarely tests every possible item on a machine while unit testing, and yes one thing can affect another. If it’s not obvious, then a defect makes sense, how else do you track time put into looking at the issue? -. Restarting machine? Uh… yeah… you know code is server deployed right? If you’ve heard that or think that is actually a used excuse, you haven’t… Read more »

els
els
8 years ago

All of these questions are valid. One tester that I worked with was always saying that he could not see the fix or a feature on the development environment. I always test my code before progressing to the next stage, so there are valid reasons. What I kept having to repeat to him was “did you clear the cache?” He’d say “no”. That ended up being the very first thing I’d ask him, and miraculously, there wasn’t any issue any longer! Number 6 and 4: I get this all the time. I’m working on something critical, and I’m interrupted to… Read more »

Back to top button