use make and version control system for every project?

[Peter Hansen]

Cameron Laird wrote:
> 
> How often "do you need to know when a bug was fixed"?
> Often, still; it certainly arises.  For the most
> part, though, in 2003 there's a healthy emphasis on
> making what's right in front of us--the current
> version--correct, rather than just "fixing bugs".

While I agree with this positive view, I have to note that it is, 
to some people (I believe mostly those involved in commercial 
development), quite important to know when a bug was injected.

The reason I say that is because _we_ often spend a moment, after
we have found and fixed the bug of course, investigating why the
bug occurred in the first place.

We like to know who did it, roughly when, and if possible why.

None of this is to place blame, per se, but merely to ensure that
our process receives periodic scrutiny so we can improve it when
it fails us.  If the person who checked in the buggy code didn't
work with a partner, we need to fix that.  If the partners who 
checked in the buggy code didn't test adequately, we need to fix
that.  If the customer didn't write an acceptance test that 
covered this potential problem, we need to fix that.

We also need to know *when* so we can estimate the risk to our
customers.  How many have received code with the defect?  Have
we just detected a business-critical risk, or do we have only one
or to field-fixes which have to be organized?

Basically, having the history does often -- for us -- prove 
useful and is therefore an important part of what the revision
control system provides for us.

(Much less important on personal projects, but as I mentioned 
before, getting in the habit can be difficult so doing this whenever
possible is a Good Thing, even if the direct value is not so clear.)

-Peter