Notes on the Development Life Cycle

notes-on-dev-lifecycle.org

Notes on the Development Life Cycle

Prioritizing

• avoid changing the list of items to work on mid-sprint
  • be firm with clients – prevent them from sneaking in new items/making changes to their requested features mid-sprint
  • item priorities may change mid-sprint, but keep in mind that changes like these are disruptive
• points or man-days: YMMV
  • whichever you choose, be consistent (this is a team decision)
  • make sure everyone agrees on what each unit of effort stands for
  • estimates are not absolute

The Mythical Man Month

• if one dev can finish a task in 1 day, it DOES NOT mean that two devs can finish that same task in 1/2 day
  • different people have different work efficiencies
  • every new member you introduce into a team increases the effort needed to keep everyone’s knowledge synced

http://www.cs.virginia.edu/~evans/greatworks/mythical.pdf

Design

• maintain a wiki containing all relevant documents: requirements, specs, diagrams, etc
• recognize the limitations of your RDBMS
  • eg, just because you can implement all your logic with stored procedures doesn’t mean you should
• prefer maintainability over optimization
  • when in doubt over performance: benchmark

Development

• make sure the build is green before you leave every day
  • last-minute, hurried commits are generally a bad idea
• avoid commenting out tests just to make the build green
  • outdated tests need to be updated
• if your build takes too long, you may need to remove/optimize certain parts of the build process

Deployments

• automate as much of this as you can – deployment by hand is error-prone
• if you have a testing phase prior to deployment, avoid sneaking features in during testing
  • if not, consider having a “no coding” period (eg, 1 day) prior to deployment (make sure the build is green)
  • bugfixes, hotfixes, etc should have their own branches
• consider tagging deployed builds for future reference

Maintenance

• anticipate requests for long-term support
• if the original developers are still around, have them document as much about the project as they can
  • and train the maintainers, if possible

Retrospectives

• sprint retros, project retros (aka the post mortem)
  • YMMV on what you need; either way, you need to document what went well, what went wrong, etc for future reference
• retros are a team affair: do not include clients/non-members
  • members need to feel safe enough to be honest about what went wrong
• burnout is a result of unsustainable practices
  • overtime is a last resort, not a silver bullet – remember the law of diminishing returns