Building software is unpredictable.

Because of this inherent unpredictability, you should never constrain both a ship date and a feature list for a projected release. Not even adding more people to a project will get around this law. As Fred Brooks famously taught, “adding manpower to a late software project makes it later.”

This a hard, inconvenient truth about software, and it makes many activities very difficult (marketing future releases, negotiating contracts, creating product road-maps), but ignoring it causes conflict and dysfunctional behavior.

Process Suggestions:

• Pick a release cadence, like once a month, and ship whatever you have.
• Pick a set of features and ship whenever it is finished.
• Market what you have, not what you will have.
• Do not rely too heavily on long term road-maps, as they are likely to change.
• Do not force programmers to commit to complete certain features by the end of a sprint or by a certain date.

Process is not free. It will affect productivity and morale — often dramatically.

All process comes at a price. The lightest, leanest process you can get away with is always best — and you will be amazed how very little process you really need. Programmers are largely self-managing and self-motivated.

Process Suggestions:

• Resist the desire to track everything. This usually leads to intrusive processes and tools.
• Allow each individual programmers to track their tasks with whatever tool they prefer. This may be Post-It notes, pen and paper, or software — whatever makes them productive and does not get in their way.
• Programmers thrive in a flat organizational structure. In fact, many forward thinking corporations have done extraordinarily well with no managers at all (ex. Valve, Medium, Zappos, Treehouse).

Software is never “done”. It asymptotically approaches completion, but will only meet it at infinity.

There will always be bugs in your software. There will always be tweaks to be made to your user experience. There will always be code that needs to be cleaned up. There will always be more tests to be written. And there will always be more documentation to write. Because there is always more work to be completed, you will have to make a judgment call about when to stop. Therefore, “done” is a decision not a definition.

Process Suggestions:

• Do not attempt to collect metrics or enforce standards to automate this decision.
• Trust the intuition of your programmers in this matter. Self-pride and prestige will drive the product to a sufficient quality level without interference.

Programmers need long periods of uninterrupted concentration.

Ideally, programmers will work remotely or have private offices, or both. Collaboration should be asynchronous and online whenever possible, allowing remote efforts to be on equal footing with on-premise work and to give permanent record to items discussed.

Process Suggestions:

• Have everyone do meetings online even if many of the programmers are working in the same office.
• Use video/voice tools (Hangouts, Skype, FaceTime) sparingly. Prefer less intrusive, asynchronous tools (IM, email, internal Reddit clone, IRC, etc.)
• Avoid open office layouts like the plague.

Coding is more like design or art than manufacturing.

Consider the absurdity of asking a sculptor to estimate how long it would take to complete a statue’s arm or making him commit to complete it before the end of a two week sprint. A sculptor has a process completely his own. Perhaps he sketches his projects first; maybe he builds a fully completed version out of plaster before even starting with the final material. It is best to leave him alone to carry out his work. Imposing an exterior model on his efforts would only result in frustration, poor quality and delay.

This is true for many creative workers and applies equally to writing software. Analogously, each programmer has his own way of working. Some like to draw class diagrams while others like to start by coding a prototype. Some use a top down approach while others use a bottom up one. And because of the immense complexities at play in creating software, most programmers have assembled a battle tested set of tools and techniques to wrangle this complexity. It is best to not interfere.

In addition, like designers and artists, programmers can and should even be trusted to make correct product decisions. Just as an architect would decide how many doors and windows to sketch on a blueprint, programmers can make feature decisions that will contribute to an effective and cohesive end product. Historically, many of the most successful software companies were formed by a group of talented programmers operating without product direction.

Process Suggestions:

• Assign areas of responsibility instead of specific tasks to your programmers. They will know how to attack the problem. Don’t waste time estimating, planning or designing tasks as a team if those tasks lie within someone’s individual area of responsibility.
• Limit collaborative planning and design to specifying interfaces between individual programmer’s responsibilities.
• If more than one person must work inside a single area of responsibility, still assign one programmer to be in charge and give him full executive authority. Others can contribute by submitting suggested changes to him that he can reject or accept based on their quality and utility. This model is best exhibited in Open Source projects.
• Make your product department be a service organization that provides feedback and information to programmers but that does not direct or manage their work. Let programmers make the final calls about what features to build.