Should I record a bug that I discovered and patched

Is there a point at which the process gets in the way and becomes an end unto itself?

Heavy processes are common, unfortunately. Some people - especially management - religiously imagine that processes produce products. So they overdo the processes and forget that it's really a handful of hard-working, smart people who actually create the products. For upper management, it's frightening to even think that their business is in the hands of few geeks, and so the close their eyes from the reality and think of their dear "process" instead, which gives them the illusion of control.

That's why agile startups with a handful of good engineers can beat big, established corporations, whose workers spend 95 % of their energy on process and reporting. Some examples of once small startups that once did beat their competitors and/or created completely new markets:

• Apple (Apple I was created by 1 engineer; there were 3 men at the company back then).
• Google (created originally by 2 programmers).
• Facebook (1-man effort originally).
• Microsoft (2-man company in 1975).

One could easily say that these are just outliers, extreme exceptions, and to do something serious, you'd better be a big, established corporation. But the list goes on. And on. It's embarrassingly long. Almost every today-major corporation started as a garage shop, which did something unusual. Something weird. They were doing it wrong. Do you think they were doing it according to the process?

To put bug analysis in there is a good practice, for the reasons you mentioned (just avoid being overly verbose).

This way, people reading it (including your future self) would know how much tricky the issue was and how much effort went in analysis and findings. Also, this way simplifies maintenance in the case when further changes are required related to your fix, because one could read bug report and understand why things were changed one or another way.

_{Just don't expect this to directly make you get noticed by higher management, because this is a different matter, a matter of workplace visibility, and this would require other skills and approaches. For the purpose of visibility, details you put into bug reports play only auxiliary, secondary role, allowing you to quickly find and get these details when necessary. Being capable to quickly pull out a clear explanation for tricky technical matters may give one a certain edge visibility wise, but it does not guarantee a major advantage.}

To put fix code (except for snippets that are relevant in your analysis) into a bug report is another matter, typically a bad practice, as it is expected to be in VCS.

Good issue trackers integrated with VCS can even automatically refer readers to changes related to the fix. For an example on how this could be, take a look on Integrating JIRA with Subversion:

JIRA's Subversion integration lets you see Subversion commit information relevant to each issue. Subversion integration can be implemented either by using Atlassian FishEye or the Subversion add-on... both solutions allow you to link JIRA to related code changes in Subversion.

Commits will appear in this tab if the commit log mentions the issue key ('TEST-3' above)...