Following the best practices is all fine and dandy. But what happens under pressure, when deadline is approaching, PROD is down, and CIO is breathing down your neck? In most companies, all the practices are simply dropped and people just do whatever "fastest" thing they can. "Fastest" usually means such that feels simpler, i.e. requires less emotional energy. This approach usually leads to adoption of quick-and-dirty solutions commonly known as The Ball Of Mud that start as temporary and end up being permanent .
Instead, I propose to bring some order into this process and establish a sequence in which the best practices should be surrendered. While you can argue what specific items and their relative priorities would work better in your team, it is my strong opinion that the concept of such list is universally applicable.
Here's my first take of such a list, starting with the items I would drop first (documentation), and finishing with the ultimate rejection (not developing anything altogether). I would be really interested to see what your list would look like, please reply in the comments.
- Design Documentation
- Performance micro-optimizations (at the code level)
- Following official company-prescribed coding standards
- Ensuring the solution will work with Continuous Integration (unit-tests running on check-in)
- Adherence to low-level design standards (S.O.L.I.D. principles of OOD)
- Sufficient research of design/implementation approaches (e.g. on the internet) done before coding
- Neat code formatting
- Adherence to basic coding standards (small classes, small methods, no copy/paste etc.)
- Discussing solution with other team members
- Ensuring solution will work with Automated Builds process
- Adding or updating unit-tests
- Ensuring the solution won’t incur extra maintenance overhead
- Ensuring the solution will not negatively affect other systems it has no direct relationship to (e.g. overall system performance etc.)
- Manual testing done before pushing to PROD
- Whether the solution should be developed altogether
This list works at a subtler level than its simple structure would suggest. It changes the holy war attitude, the black and white attitude, of "professionals always do documentation", "agilists could care less about documentation, but they always do unit-tests" etc. to a much more workable prioritized sequence. Also, by contrasting practices well-known in management circles (such as coding standards) with those well-known by junior programmers (performance) and agile programmers (unit-tests) the practices are put into context of relative benefit/harm their adoption/rejection does to the big picture.
I strongly encourage you to create such list, thoroughly discuss it with your team, make sure everybody understands each item and has a chance to argue about its place in the sequence. You may even want to hang the list on the cubicle walls, which is what I plan to do once I finalize it with the team.
Tags: