What do you mean, don't submit bugs?

• Developers are lazy like everyone. They often change the code without proper code comments, they will often miss the version control comments as well.
• The developer will go away as soon as he cannot tell from his own code after few years, what it should do. And in this case you will be in trouble.
• The changes will not be documented, which is a problem in case of a product. The issues are important to generate release note and documentation from

...the one concern I have is not being able to analyze issues for patterns.

Waaaay back when I first learned about XP, it was suggested that the team should perform Root Cause Analysis for each defect found. This meant:

• Finding and fixing the defect, of course;
• Looking at the type of defect and determining if there are any other places in the system where that sort of defect could occur;
• Examining the team's process to try to understand how the defect was introduced in the first place, and how to prevent it from being introduced in the future.

James Shore included this in The Art of Agile Development.

This could take 5 minutes or it could take hours depending on the situation, but it helps provide the analysis and pattern detection that you mention. It also eliminates the need for a defect tracking tool *and* addresses Gabor's concern about "lazy developers", provided that the whole team participates.

There are situations where it doesn't make sense to do this, such as a typo on a screen or web page - just fix it and move on. However, the investment of the time to perform RCA will pay off in the future as the team doesn't submit the same types of bugs over and over and over.

In the end, this is as much a mindset change as anything else - anything greater than 0 defects is unacceptable!

Gabor, might have missed the point,

this is about nothing else than about small bugs:

If a tester is testing a user story card within the scope of a sprint and finds a small problem that can be fixed easily,

Some things are faster corrected than you can file a bug.

Silly little bugs, wrong labels, mispelled labels, etc. pp.

Developers are lazy like everyone. They often change the code without proper code comments, 

Personally, i can not think of what a "proper code comment" should be, or why you would want to write inline comments, be it to describe bug fixes or anything else, write a bug report for a real bug and write a test.

- Developers Leave.

Automated tests don't.

- Developers sometimes change teams / projects

Automated tests don't.

- Knowledge gained about what caused the bug is lost

Automated tests aren't.

- Depending on word-of-mouth to share lessons learned is inherently inefficient

Automated tests aren't word of mouth, and they can be execute as often as you wish.

- The "how it was fixed" is lost

Automated tests capture this.

- Defects have a funny way of showing up again - memories are weak mechanisms for retrieving knowledge

Root Cause Analysis. On every non-trivial bug (and even some of the trivial ones). And, of course, automated tests should ensure that the same bug doesn't come back.

Just 'cus you fixed it doesn't mean that you learned anything that will prevent it from happening again. I'm not talking about the Spanish Inquisition, but rather investing a small amount of time to learn how to prevent defects rather than trying to find them after the fact.

dawn,

believe me - the bugtracker is your friend.

you work as 'serious tester' (lets say) as a quality gate after your programmers. fine. 

now someone whispered in your ear that bug-reports are bad - makes too much work - having an eye-to-eye coffee with the developer chatting over some anomalies in his artifacts is more fun..

when you do that for a while, some cost-sensitive senior shows up at your place and asks 'what exactly are you doing?' - is it effective? - is it efficient? - do we need you? 

how do you prove that you ARE important ? without numbers? 

No bug-reports means EITHER: developers are perfect (like me) and make very few mistakes (like me) - then your testing-job is not needed. OR: you test but dont really find bugs - maybe you are not right for the job??

 the bugtracker is your friend!

A proper code comment looks like this:

// If this is a root element then the parentId will be null.

...or this:

//  We must check to make sure that the cron has finished before committing updates to the database or else we will corrupt 95 terabytes of data and go out of business over night.

It is easy to see what good code does, it is not always so easy to understand why it does things in a particular way.

// If this is a root element then the parentId will be null.

Lets say you're putting this inline comment over a method like this:

private boolean isRoot(final Node node) {
    return null == node.getParent().getId();
}

or even

public class Node {
...
    public boolean isRoot() {
        return null == this.parent().getId();
    }
...
} 

Would you still think it is necessary?

I'd say it is superflous and leave it out.(first one is breaking the law of demeter btw.)

The trick is to write your code in a way that it becomes expressive, everytime you write an inline comment, think again. Keep your methods short and sweet so you'll have plenty of opportunities to use expressive and intention revealing names.

OTOH, i you have this if condition inside of a 200 line method

if (null == node.getParent().getId()) {
.. another 50 lines of code here
}

you cannot make up for it by using an inline comment, it stinks IMO.

As for you second example, this should be part of the documentationen and not just buried somewhere in code/implementation details, at least put it into the JavaDoc.

No, any moron could deduce my comment from your method (isRoot()).

Exactly,if even morons could understand code that was written this way, the comment is redundant, it won't add any additional information.

You missed my point. 

Whats your point?

Restating obvious facts that become clear when reading the code in a redundant way by using inline comments?

 Inline comments are meant to give context as to WHY something is being done in a particular way, not WHAT is being done, and are only useful when WHAT is being done does not necessarilly shed light on WHY it is being done that way.

 No, this is what documentaiton if for, like JavaDoc. What and how it is done must be clear from the code itself, it's called "implementantion details".

Too exaggerate your example, some of the worst code I have ever seen looks like a method farm - hundreds of virtually pointless tiny little methods making it nearly impossible to attain any sense of context in the bigger picture.m

Again, you cannot make up for bad code by using inline comments, inline comments are a sign for bad code. By writing small methods you gain a lots of advantages, like burying dirty implemenation details in private methods, using public methods to give an coarse grained overview of whats gonna happen.

Worst code i've ever seen was made up of few classes with huge methods and many inline comments (many of them outdated or wrong due to c&p) and no unit tests at all.

 Regarding my second example, I assume that would be in the documentation, email, wiki, sung in 5 part harmony at company meetings, and carved on the inside of the bathroom stall in addition to being mentioned as an inline comment at the single point where it actually matters, in the source code.

Funny you mention "in documentation" as opposed to "burried somewhere in code". I would reverse those to be "burried in documentation" as opposed to "in code". You are speaking directly to a developer when using an inline comment about a specific line or block of code that you have created and that they are now reading. Perhaps you are reading it to remind yourself in the future of WHY you did something in a particular way. Or perhaps you are reading it to understand WHY somebody else did it in a particular way. 

JavaDoc is also part of the source, but readable without having to read the source.

Do you expect a developer always to read the implementaton when he is calling a method? If the dev doesn't read the source, he would miss your hint if it was written as inline comment.

The comment may be it a warning, appology, plea for better code, or challenge for the same. You can't do that in Javadocs or specs. 

Inline comments are a sign of bad code, usually because the devloper didn't know any better. You can warn/apologies etc in JavaDoc, or why wouldn't you be able to do that?

OTOH, you could write clean code and forget about the apology ;)