"Enough of Processes" or the Ascendancy of the "Toolbox" approach

We've all seen the arguments for and against RUP/CMM and other BDUF approaches vs. the pros and cons of the Agile crowd (e.g. XP, Scrum, Crystal etc.) and I've gotten to the point personally, that although many of the arguments made by both sides are true and valid, fundamentally they don't have much impact onto the average developers day - you're either on one side or the other and don't have much say in how it goes.

(I do think there's a lot to be said for someone -doing a thorough and unbiased (if that's possible) empirical study into the pros and cons of each approach.)

But the real problem is that most if not all of these processes are so very much "All or None". You're either all RUP/CMM or all XP/Scrum etc. So over the years I've developed what I call my "Toolbox" approach - I bring a set of best practices with me that neatly fit into most processes agile or BDUF.

So it was interesting that it seems that Ivar Jacobson is getting there too.

Anyway, in that vein, the following is a list of practices that (I hope) most people can agree are worthwhile regardless of where they sit on the process/no-process or BDUF/Agile fence.

1) "One Click" Builds
Be able the build the entire application front-to-back with one command / click of a button ( e.g. "ant build" or some such)

2) Continuous Automated Builds
Have a dedicated build-server that detects any and all code check-ins and starts a build. It then emails the results to everyone including a list of what files have changed (and ideally the developer's check-in comments)

3) Unit Test immediately after #2
Run your unit tests immediately following the automated build and email the results to everyone. Oh and keep the unit tests working - don't let them slide!

4) Use Source-Code Control
Do I really need to still say this?

5) Use a bug tracking system
Again should be obvious

6) Prefer prototypes over long requirements documents
Use prototypes to cut requirements documents down to the core (intent?) and ensure that users get an idea of what functionality they will get and how it will work.

7) Run User-test level Regression Tests
Use tools (such as Segue Silk, HttpUnit etc.) to automatically run user-tests every night (in addition to unit tests these act as a more complete smoke/regression test) .

8) Use Code Coverage Tools
Use Code coverage tools (e.g. Emma, Clover, JCoverage) alongside your unit and smoke tests to help you understand what code is being tested, and more importantly what is *not* being tested.

9) Provide Test Data
If tests are data driven, provide each developer with access to a "golden copy" of the database
against which unit tests can be written and make it easy to reload that DB and do it quickly.

10) Use tools to do automatic code checking
I've talked ad nauseum about Checkstyle / PMD / Findbugs etc. Great tools!

11) Keep on a steady upgrade path
On a regular basis ( e.g. yearly) make sure you upgrade to the next patch or major release of key things such as the JRE, your container (if any), your database etc. Focus on the core stuff. You should not bundle all these together at once (risk!) but you should try to tie in your applications major releases with some upgrades (so you don't fall too far behind the technology curve).

12) Give developer's tools to ease and encourage communication
Nice meeting rooms with Wi-fi (no more frigging cables!), IM, white-boards with attached printers, wikis, document repositories (with *great* search capabilities - still waiting to see that), templates for word/powerpoint etc.

13) Give developer's great tools and let them work efficiently and quietly without interruption
Their own offices, access to great IDEs (NetBeans / IntelliJ / MyEclipse), two monitors (at least), dedicated test and performance environments

14) Creating Training and Quick Reference guides for the experienced as well as the newbies
Help people get up-to-speed quickly (and help reduce the cognitive load for the experienced) by providing little reference guides on various things e.g. types of things to test in a unit test, how to run the regression test scripts etc.

Keep documents light, picture-focused and up-to-date.

Conclusion
Note that many of the tools / techniques I push for are focused on the automation of tasks, with early issue identification (e.g. broken builds, broken unit tests, broken unit tests). These tools surround the developer in what I like to call the "Developer Cocoon" - enable the developer to write the best code they can as fast as they can but automate the drudgery of testing and finding issues (of course this automation relies on the developer's desire to write and maintain unit tests and user tests continuously).

One of my peers who I really respect once summed all this up quite succinctly "Automate EVERYTHING!"

But the point of this is that many, if not most of these practices, I think we can all agree upon as valuable and worthwhile and from this try to get the emphasis on what we do agree upon rather than semi-religious arguments that focus on things we disagree upon.