The unrelated photo is of excavators adding drainage to our home on Salt Spring Island.
These suggestions seem obvious to me, but when I pitch them to teams, I often encounter a surprising amount of resistance. Part of this is probably due to the way that I pitch them - I am not a political genius; part of it is probably due to something that makes these suggestions non-intuitive or psychologically challenging to implement; part of it also might be that I am wrong, and that these aren't good practices after all. Dunno. In any case, here are a few handfuls of them:
- If you disagree with something, write a memo and let it go. The writing of the memo is as important as letting go is. Both are hard disciplines.
- Continuous Integration . The longer code diverges the harder (more expensive) it will be to merge it. Converge daily.
- Automated and opinionated code formatting . Stop debating the style. Your company is not in the business of writing a style guide.
- Canonical/conventional approaches . Given two or more viable approaches to something, choose the one that is industry standard. It is easier to on-board new developers, the documentation is already available online, and there are fewer unknown risks.
- Ship something, anything. Before we ship it is easy to fool ourselves into thinking we have a product. Keep yourself honest. Ship it.
- You are not going to need it (YANGNI) . Do not build it until you are quite sure that you will need it - the least expensive software is the software you do not write. A related point is that the best designs are extracted not envisioned.
- Red/Green/Refactor/Repeat . Since learning this approach to test driven development, my code quality and velocity has improved massively. The best way to learn this is to practice it .
- Give high level requirements and then let go . As a supervisor/manager, it is too hard to be an expert on your developers' work. Give them high level requirements and trust their decisions.
- Keep "issue management" process to a minimum . Very little has slowed me down as a developer more that updating JIRA or Pivotal Tracker has. If you need to explain a process more than once, you probably need to simplify it.
- Keep documentation to a minimum . As usual the agile manifesto (and most open-source code bases) have it right here. Document weird stuff but not all your motivation and rationale.
- Make stand-up on time and focused . Same time every day. If someone misses it, that's fine. Answer three things: yesterday, today, obstacles. Save chit-chat for the water cooler.
Writing down this list makes it easier for me to relax when a team decides on a different path.