Dave’s Blogs

Here are my notes from Kevin Tate’s “Sustainable Software Development: An Agile Perspective”

Introduction

• “Sustainable development is a pace that can be maintained indefinitely.”
• “Sustainable development requires a singular focus on a form of technical excellence that regularly provides useful software to customers while keeping the cost of change low.”
• “Balancing the short and long term requires projects to be more driven by a vision than tracked against a plan.”

Chapter 1

• “Key indicators of sustainable development are an ability to keep the number of defects relatively constant over time while recognizing that the software must be modified to keep the cost of change under control.”
• “Working harder (more hours) results in declining capability over time. Working smarter, with an emphasis on continual improvement, leads to increasing capability”
• “Companies need people who treasure the contribution they make when at work and who are passionate about the success of the company. This has no correlation with the number of hours worked. . . ”

Chapter 2

• “Technical debt is caused by an accumulation of poor decisions over timedecisions that often seem right at the time but are usually made in the interests of a short-term quick fix to the software.”

Chapter 3

• “The most common response to flailing around is to apply bureaucracy, to define a set of strict rules and milestones that cannot be deviated from. But bureaucracy stifles innovation and is most often misguided, leading to unintended side effects. It is also inflexible and change-intolerant.”
• Great teams recognize that what they are trying to achieve is more important than how they achieve it
• Three elements of sustainable development:
  • A vision
  • “Practices that are consistent with the principles.”
  • A feedback loop that leads to enhances to practices.
• Sustainable software development principles:
  • “Continual refinement of the product and project practices.”
  • “A working product at all times.”
  • “A continual investment in and emphasis on design.”
  • “Valuing defect prevention over defect detection.”
• “Effective teams strive for the optimal balance between being visionary (thinking about the long term) and tactical (focusing on today’s problems), and this balance changes over the course of the project.”
• “Great cultures recognize talents and skills as separate from each other. Too many companies are focused on skill alone and recruit only for skills. But skills can be taught, whereas talent can’t.”

Chapter 4: Working Product

• Practice 1; No “Broken Windows” — “no hacks or ugly workarounds”
• Practice 2: Be Uncompromising about Defects — Preventing and addressing defects and put a closure (fix it or close it with a reason) before moving on.
• Practice 3: “Barely Sufficient” Documentation
• Practice 4: Continuous Integration
• Practice 5: Nightly Builds
• Practice 6: Prototyping — In addition to the traditional concept of prototyping with code, a “whiteboard and paper” approach is another quick way to gain insights from the customer(s).
• Practice 7: Don’t Neglect Performance
• Practice 8: Zero Tolerance for Memory and Resource Leaks
• Practice 9: Coding Standards and Guidelines
• Practice 10: Adopt Standards (Concentrate on Your Value-Add)
• Practice 11: Internationalize from Day One
• Practice 12: Isolate Platform Dependencies

Chapter 5
• Practice 1: Ruthless Testing — Use unit tests, mock objects, integration testing (when using 3rd party libraries), system testing (that simulate real user loads), performance testing, Resource-usage testing,
• Practice 2: Use Available Tools — Source code analyzer such as PMD.
• Practice 3: Pair Programming and Code Reviews
• Practice 4: Lightweight Root-Cause Analysis — 1. What cause the defect? 2. What would have caught this defect? 3. How can we prevent this from happening again?

Chapter 6

• Practice 1: Design Vision
• Practice 2: Guiding Principles
• Practice 3: Simple Design – If you see an opportunity to design for a future need, do it and make that architecture work visible to users. The goal is to avoid costly refactor work.
• Practice 4: Refactoring
• Practice 5: Design Patterns — Watch out potential over use of patterns that could be solved with simipler implementations. Sometimes pattern implementations might vary greatly or even have different behaviors.
• Practice 6: Frequent Rapid Design Meetings
• Practice 7: Commitment to Rearchitecture – Use existing tests to check for regression.
• Practice 8: Design for Reuse

Chapter 7

• “the challenge with agile methods is to rely on both adaptability and anticipation and to have a team that knows when and how to apply each, and in what measure.”
• Practice 1: Iterative Development
• Practice 2: Release Planning
  “as with any project, you can either change the date, the feature set, or the resources. You can’t expect to fix all three.”
• Practice 3: Daily Standup Meetings — What you did? What are you doing? What is stopping you?
• Practice 4: Retrospectives — “What worked well?” “What needs to be improved?” “What should we do differently?”
• Practice 5: Coaching and Team Development — It’s important that developers understand what’s important to the customers, which will infer how the customers use the product. Note that how the customers use the product (i.e. what they really asking for) maybe differ from what they asking for. “If the only value you provide to an organization is writing code, then your job can be outsourced (i.e., worked on by cheaper labor).”
• Practice 6: Make Key Metrics Visible

Chapter 8

• Required Change factors: Leadership, a sense of urgency, and executive support
• Change enablers: persistence, training, continual wins, positive reinforcement of desired behaviors, communication, vision, and strategy.