chonton / productivity

Thoughts and ramblings on best practices for productive software development

Personal and Team Productivity

A software development philosophy

"It is not the strongest of the species that survives, nor the most intelligent, but the one most responsive to change." -- L.C. Megginson

Document Policies & Procedures

Keep a concise set of policies and procedures. The policies are requirements in addition to the end-user features which you are implementing. Use the procedures as a guide for how to organize your work.

Identify Stakeholders

Who has a stake in the product you are producing? There are end-users, operational teams, regulatory bodies, open source communities, and other organizations that may have desires and requirements to fulfill.

Prioritize

Set your priorities. Determine which stakeholders have higher priority and what are minimal requirements for each feature. Remember that satisfying policies is a feature.

Establish Team Norms

• How are decisions made?
• How are open discussions encouraged?
• How important is data when making decisions?
• When are the team meetings?
• How do we encourage participation?
• What is quality work?
• What feedback is expected and desired?
• How are contributions acknowledged?
• What celebrations are there?

Iterate

Use iterations to work sustainably. Break down large efforts into small chunks.

Review Work

All work should be reviewed. Product and Architecture documents must be shared with the team to gather feedback and identify obstacles. All code must be reviewed before merging to production branch. How easy is it to maintain this code?

Quality

Measure the quality of your product. How easy is your product to use?

Principles

Work isn't product

An end-user doesn't care about your work. They only care for (or not) your product.

You ain't gonna need it (yet)

YAGNI means don't spend time on anything not needed in immediate term. Any work that doesn't add to the product's delivered usability is wasted investment.

Unix Philosophy

Adopt the successful patterns of the leading Unix developers.

• Make each program do one thing well.
• The output of every program will become the input to another, as yet unknown, program.
• Try software early. Throw away and rebuild the clumsy parts.
• Automate work, even if automation is a detour, and expect to throw out some automation after use.

An interesting comparison that illustrates the first two points is sendmail vs qmail.

Automation

Automate any process which offers at least as much time savings as the cost of building the automation.

This work is licensed under a Creative Commons Attribution 4.0 International License.