Pragmatic Programmer Techniques - who, what, where...

Question

Few questions. But all very much related.

1) How many of the SO crowd are using 'pragmatic programmer' tools/methods/techniques including, but not limited to (some of the obvious):

a) Source code control system.
b) Active use of branching, tagging with SCS.
c) Task/Bug tracking (integrated with SCS).
d) If DB development is involved, local DB development PER dev machine,as opposed to 1 central DB dev server.
e) Mechanism for DB version control.
f) Test Driven development.
g) XP, pair programming
h) Automated functional testing.
i) Continous integration.
j) Automated deployment/release management/packaging (with or w/o Continous Integration).
k) Peer code reviews.

I would be really interested in seeing what specific tools (any platform) people on SO are using for the above.

2) What percentage of developer teams (yes, including non-SO crowd!) of at a minimum 3 devs, do you think are applying most (say 6 or more) of the above techniques?

3) If you ended up working in a place where they had only a), and you could introduce 3 more, which ones would you go for? in other words which 4-5 or so do you think are most important?

4) Can you think of any more 'pragmatic programmer' bullets. Can we get to z)?

Thanks!

Answer 1

1) Being a contractor, it's different at every gig. Currently:

a) Subversion
b) Branching, release tagging.
c) Trac
d) Local DB dev
e) TSQL scripts with strict naming convention in source control. Diff's on main ALTER script for incremental changes.
f) Yes, but nowhere NEAR even 50% coverage. Just be honest. ;-)
g) Nope.
h) Not yet - talked about Selenium and some HP test product.
i) Yes, CruiseControl.NET.
j) Yes, using CCNET and MSBuild.
k) Nope.

2) Definitely 80-90% will use a SCS, but 6 or more of the techniques listed won't be used by more than 50% of dev teams I'd guess. And that's probably being too conservative. It could well be much lower.

3) Task/Bug tracking, Continous Integration, DB version control third or Peer code reviews third.

4) Nope, not yet.

Answer 2

Right now, we do the following

a) CVS, Perforce 
b) Tagging, via Maven release 
c) Yes, via corporate system 
d) N/A; our code deals with multi-terabyte datasets.  
e) Half way there. We have "releases" of the schema and versions in CVS 
f) For much of the new code yes, functional and automated integration testing for a lot of the old code. I doubt we have 50% coverage.
g) I wish. 
h) Hudson  
i) Hudson 
j) Hudson/Nexus
k) We do code reviews and design reviews (I call them code previews)

Answer 3

a) Source code control system.
Yes - I have even convinced approx 25% of other programmers I worked with to use it!

b) Active use of branching, tagging with SCS.
Yes - nearly understand it in SVN, must be time to move to Git!

c) Task/Bug tracking (integrated with SCS).
Integrated with sales guy/manager volume level

f) Test Driven development.
Well it works on my machine

g) XP, pair programming
There's only me but I have a split personality

h) Automated functional testing.
Well they automatically they assume I do it all.

i) Continous integration.
Salesman shouts, I code, it builds, he ships it - continuous enough?

j) Automated deployment/release management/packaging (with or w/o Continous Integration).
Behold the glory of the DOS batch file (which calls, other batch files, make and python = job security)

k) Peer code reviews.
Does the cat count?