Home » Software Development » Common excuses a Developer makes when a feature doesn’t work [And how to avoid them in the future]

About Rajaraman Raghuraman

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.

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.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you our best selling eBooks for FREE!


1. JPA Mini Book

2. JVM Troubleshooting Guide

3. JUnit Tutorial for Unit Testing

4. Java Annotations Tutorial

5. Java Interview Questions

6. Spring Interview Questions

7. Android UI Design


and many more ....




  1. “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 time to dig into the code and reproduce your problem.” and I think that’s one of the best things you can get, if it’s not an obvious problem.

    Maybe I have to:
    – read the logfile
    – check if the database is running
    – check if services are online
    – check code from a 3rd party library
    – whatever.

  2. 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 there can be side effects. This is often the case with bigger software. In some cases the idea is thats the problem.
    #3 – configuration can become complicated. This is not an excuse, this is an analysis.
    #4 – then don’t call it defect, call it an issue. It doesn’t matter. The point is that we developer are having serious problems with getting things done in a specific time frame. Blame Scrum. Whatever. But one cannot always look in an instant in an issue, just when somebody comes to the desk.
    #5 – does it hurt you to restart your machine when the developer thinks it could be the root cause?
    #7 – well what about outside dependencies, like consuming third party services?
    #8 – sure it can be an environment problem. It needs to be checked.

    The only excuse i can see is #1. “It works fine on my machine” doesn’t help – the goal is to work on all target machines.

    However to read this post was a waste of time and to write this answer was even more waste of time. Now I am going back to do something productive and kick some bugs.

    • 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 a problem with that.

      • 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 for not having a solution as soon as you report a (possible) issue? Maybe it’s a gentle way to say ‘I’m working on a higher priority issue, please wait until I can focus on the problem you’re reporting’
        4 – Similar to 6: I don’t have a immediate solution (like rebooting your machine :-P see point 5) and I cannot interrupt the task I’m working on. Since I can forget about your report in the future, please signal the issue so that it can be tracked and maybe solved by someone else.

        Overall, you seem to work in teams where there’s no trust between members: you shouldn’t need to ‘avoid’ excuses: as a tester, you should work with your colleagues in order to let them understand that you’re doing them a favor when you report an issue.

        Lame article, indeed.

  3. Nice response lacopo

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

  5. 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. In 50% of the cases, the problem is that the person is doing something the wrong way (and not telling the complete story), in 20% of the cases it’s some weird settings on the person’s machine or conflicting requirements. In another 20% of the cases, it’s a technical problem that the programmer has really nothing to do with it (firewall, routing, etc…).

    Generally, in 10% of the cases, there is an actual bug that needs to be solved. Other than that, it’s a user problem that the programmer has nothing to do with.

  6. Clear the cache!!!!!!!!!!!!!!!!!!!!!!!!!! :)

  7. 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 either developed at all or in the last 10 years.
    – “6. I am not sure why it isn’t working. Let me check it” How is this an excuse?

    I call b.s. on your credentials, you’ve never been a developer.

  8. 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 look at a possible issue. I do have a look at times, but once I am interrupted, then that takes me time to get back to what I was working on. The management actually inform testers to raise a bug if they are unsure, so this can be tracked as they know how busy the developers are. We’re not meaning to be awkward — we just have a lot of responsibilities. I’ve worked with testers who were very needy and constantly interrupted us for wanting their every whim answered straight away (instead of simply providing a list of questions to speak to developers about later). This may be a difficult balance to get.

    Number 6 should not be a criticism at all!!! It’s saying “I don’t know; I need to look into it!” It could be one of many things, but it needs an investigation. And perhaps at that whim, I cannot look at this as I want 15 minutes to sort out what I was working on and then I can look into it and get back to the tester.

    Testers should be helping instead of hindering. Instead of a developer always constantly asking the tester “have you cleared your cache”, “have you checked the build number”, “have you checked the notes in the Jira for documentation on what configuration needs to be set up?”, then maybe testers should have a ticklist of things to check before they interrupt for help?

Leave a Reply

Your email address will not be published. Required fields are marked *


Want to take your Java skills to the next level?

Grab our programming books for FREE!

Here are some of the eBooks you will get:

  • Spring Interview QnA
  • Multithreading & Concurrency QnA
  • JPA Minibook
  • JVM Troubleshooting Guide
  • Advanced Java
  • Java Interview QnA
  • Java Design Patterns