Musings

During my time as a software developer, I’ve observed that many of the problems affecting product development in the software world can be resolved if you follow the following rules. Product and project managers: please take note.

• Make sure you know what you are building. Many project delays are because the “customer”- the manager, corporate head, (you?) doesn’t actually know what they want. Recognize that what you need to build will change all the time. Make sure your process supports this and that you reconcile the change with the point above.

• Make sure you only work on things that you need to ship with version 1.0.
• Make sure you always keep the prototype running.
• Show demos every few days to make sure no one is confused about what is going on.
• Don’t make any project your time to show how clever, cute, or interesting you can be.
• Small is good. Keep Teams/Egos/Methods/Files/Modules/Projects/build times small.
• If someone is not clicking with the rest of the team:
  1. talk to them privately,
  2. reassign them,
  3. if this person is you, read #9, and consider if you want to build this project, or do something else. Follow your heart.
• Do the riskiest part of the project first.
• Make sure you’re in total control of your toolset and improve it systematically
• Do not take the clients’ deadlines literally – first accept the project, then renegotiate the deadline. I do not mean to imply that the clients’ constraints are not important. I’ve seen too many examples of team heroics to meet deadlines, when it would have been OK from the client’s perspective to slip by a reasonable amount of time. Keep the lines of communication open and balance the needs of both parties.

• Design your software around interfaces so you can make massive changes cheaply.
• Document the interfaces perfectly, but don’t document code (see next point).
• Be fanatical about the readability of code.
• Remember that the enemy of the better is the best.
• Push all QC, packaging, and issue management through a single team.
• Build regression testing into the build process.
• When debugging a problem, never ask, “how come it works on my box?”
• If some code is too complex to understand on a Monday morning before coffee, redesign it.
• Never add new code while there are still major bugs in the existing code.
• Don’t worry about it. If you are working hard, and follow 1-19, you are doing your part.