Rajaraman Raghuraman

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

Related Whitepaper:

Software Architecture

This guide will introduce you to the world of Software Architecture!

This 162 page guide will cover topics within the field of software architecture including: software architecture as a solution balancing the concerns of different stakeholders, quality assurance, methods to describe and evaluate architectures, the influence of architecture on reuse, and the life cycle of a system and its architecture. This guide concludes with a comparison between the professions of software architect and software engineer.

Get it Now!  

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

  1. Thomas says:

    “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. Christian says:

    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.

      • Iacopo says:

        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. Mike says:

    Nice response lacopo

  4. Matthew says:

    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. Nanni says:

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

  7. deadhorse says:

    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.

Leave a Reply

× three = 15

Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

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

Get ready to Rock!
You can download the complementary eBooks using the links below: