The Principles of Sustained Software Development

1. The Principles of Sustained Software Development Lecture 2 CIS 6101 – Software Processes and Metrics

2. 1. Introduction • We normally develop software based on required features, bug fixing, and a plan. • Plans are typically linear, start with analysis and design, continue with coding, testing, fixing, tracking against the plan and customer use. • This engineering plan that does not work too well for software. • Real world of software development involves a changing ecosystem of technology, competitors, and customers • Until programmers are exposed to this commercial system, none of this seems significant. • Then, all of a sudden, they write code and must live with it. • And, the code they live with is not just their code either!!

3. Bridge from Academic to Practical • Must establish a mindset to create a culture of software development for sustained development despite surrounding complexity • Without the proper mindset, developers fall back to traditional linear approaches due to a degree of comfort and familiarity. • Here, too little structure in code-then-fix development) or too much bureaucracy which tends to stifle innovation, flexibility, and change tolerance – the very properties a dynamic and changing environment requires.

4. Practice versus Principles • Practices often viewed as templates for success. • In truth, practices must be tuned to the situation and the team. (no one size fits all!) • Bureaucratic rules are in place for predictability, which is often achieved but at the cost of innovation and ability to respond to customer requests. • We can implement practices, but we need the right mindset / culture to support the practices, for you’d be better off doing ad-hoc software development. • Before a team talks about development practices, we need to first focus on the principles to be followed. • Principles guide us every day making tradeoffs and fostering the right mindset and culture for the team and organization; • Practices follow from the principles you choose to adopt.

5. 2. Why Principles are More Important than Practices • Similar to difference between vision and features. • Unsuccessful projects start with defining features designed to meet user needs. (the Whats) • Successful projects start with a clear user need and vision of HOW to meet that need. • The vision is simple and can be used to develop an initial set of features and a prototype for customer feedback, needed to refine the feature set. • This is iterative development (as it is called in agile software development)

6. Key Aspects in Vision-Oriented Approach to Produce Development 1. A user need and vision so it is clear WHAT is being built 2. Rapid refinement to adapt to change 3. A close relationship with users so they can provide timely feedback 4. Continual learning to refine the product so it best meets user needs while avoiding unnecessary features.

7. Rules (Lists of Practices) • No magic set. • Our education specifies a set of rules (step-by-step procedures) to solve problems. • But problems arise as we rarely anticipate the role of complexity in the application of the rules. • Rules work fine for simple problems but break down as complexity increases.

8. Principles and Practices (Vision and Features) • Principles are like vision; practices like features. • Principles define what you want to accomplish; practices define how you want to go about it. • Too much today is around sets of practices (best practices) • Again, following a set of practices implies safety, comfort, completeness, predictability, sense of confidence… • Practices are important, but if you don’t know what you are trying to achieve, then efforts will be misdirected. • More important to recognize WHAT team is trying to achieve rather than HOW they achieve it.

9. Principles and Practices (Vision and Features) • Good teams listen to practices and ask questions as to what (vision) they are trying to achieve, and apply the practices as needed. • Great teams see through the rule-based façade (practices) and see the rules as a solid foundation to build on. • Great teams work from a clear user need (high user value through features and high quality) and a vision (the principles) and continually learn and refine their approach (the practices) as their project progresses.

10. Three Elements to Sustainable Development • Summarizing: a development team needs: • 1. A vision and set of guiding principles that define what needs to be accomplished • 2. Practices that are consistent with the principles (these are not a set of rules; rather building blocks that your team should refine and add to over time through continual improvement of your approach to software development) • 3. A tight feedback loop of experimentation, learning, and refinement so that during the development of the product the project team is able to change, modify, and enhance their practices as required so the team can best fulfill the principles (vision).

11. 3. Applying the Principles of Sustainable Development • Given a clear vision and desire to achieve sustainable software development, these principles apply: • 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 Practices support these principles. Let’s look at each principle in turn.

12. Principle: Continual Refinement of Product and Project Practices • This is a recurring theme in software development. • Software is complex and must evolve over a long period in the face of changing requirements and evolving ecosystem • Markets, partners, technologies, and competition • Things change during development • Team must plan for change by employing practices to support managing change. • Thus team needs user involvement and lightweight practices to keep on track, monitor progress and risks. • The set of practices establishes the heartbeat (rhythm) of the project and is a must for successful sustained development.

13. Principle: A Working Product at All Times • Keep product in a near-shippable state at all times, even if it is not functionally complete. Product needs to be in a working state. • Means emphasis of team is a working product and not producing documentation of user requirements, software design, etc. that ‘might’ lead a product. • This is a key principle of agile development. • Best way to get feedback is to provide users something they can reallycommenton, even if it is a work in progress. • Documentation, even really good documentation, does not elicit the same quality of feedback that a working product can. • Even prototypes are better than a document. • Working documents also show the time is being spent on productive activities. If too much time is spent on documentation, then time will need to be spent on getting the product back to a working state, which is time often wasted.

14. Principle: A Continual Emphasis on Design • Design (both good and poor) is very obvious and heavily influences purchasing decisions. • Design decisions are made every day and by all members of the team. • Team need so allow itself to make design changes. • Do not try to anticipate every future use at beginning of project. • Design only what you need today while not closing out possibility of future enhancements. • Agile development requires considerable design – maybe even more than traditional design. • Good design practices extendthelife of the product by keeping implementation in a healthy state • fosters maintainability and changeability – essential nowadays; • Ensures a simple long-term design vision.

15. Principle: Value Defect Prevention over Defect Detection • Defect detection involves trying to discover and fix problems after changes have been incorporated into software. • Prevention emphasizes catching defects before changes are merged into the software. • Assumption in defect detection is on defect tracking systems, manual testing efforts, and errors reaching the customer. • Organizations invest a lot in QA activities and in testing. • Tracking errors and their resolution, prioritizing, reporting, assigning fixes to proper OPRs, etc. is a huge task – and expensive. • Often, there is a virtual wall between developers and testors. • Developers develop new software and provide to QA / QC … to test prior to release. (more)

16. Principle: Value Defect Prevention over Defect Detection • In defect prevention, defect tracking systems are still needed but importance greatly reduced. • Have lower defect counts. Teams have multiple safeguards in place. • More regression testing, ensuring bug fixes properly testing, and more. • Heavy emphasis on automated testing to focus on testing the product in ways that the customer will use the products. • No virtual walls in defect prevention culture; ideally testers are part of the team and quality is spread evenly between developers, QA, and testers. • Defect prevention is required for sustainable development • Ensures team is highly efficient and is creatingvalue for customer not on wasted effort. • By minimizing defect numbers, development teams are able to have productive conversations with users about features and workflow because users are able to use the product in realistic ways.

17. 4. Culture, by Descriptive Words and Phrases: Disciplined • Team must be highly disciplined in approach and be goal focused. • Work must be done properly w/no shortcuts. • Work is really done when they say it is. • Agile development has been often labeled as being undisciplined. • Consider: Differences between Discipline and Ceremony • Ceremony – required actions must be performed • Requirements document before a certain milestone; Milestones such as a feature freeze, Weekly status meetings; Design documents; more… • Discipline - Agile teams minimize ceremony bykeeping to task; producing results (a working product ). • Unfortunately, people mistakenly believe unless documents are created, there’ s no discipline, but creating documents is no guarantee a prescribed process is being followed.

18. Culture, by Descriptive Words and Phrases: Responsible • Team must be responsible for its work and not play the part of a victim. No blame game! • Victims go along with a decision and then say, “I told you so.” • Responsible teams have the courage to take on any situation and do not get swept up by events. • They trust others to do the best they can and are diligent that nothing falls between the cracks. • Never say that ‘that can’t be done.’

19. Culture, by Descriptive Words and Phrases: Leadership • Team has multiple leaders who work together • Leaders are not just the managers, team leads, or coaches • Leaders know their greatest success is when they can help others to succeed and give them the opportunity to receive the accolades they deserve, who view success as a team accomplishment and failure as a personal responsibility, not an opportunity to apportion blame on others. • Unfortunately, these people are few and far between and are rarely promoted into senior management because they lack the charisma, high-volume talking, and massive ego and self-confidence – the traits often associated with getting ahead in the corporate world.

20. Culture, by Descriptive Words and Phrases: Visionary and Tactical • Effective teams strive for an optimal balance between visionay (thinking about the long term) and tactical (focusing on today’s problems) and this balance changes over the course of the project. • Early in project, there is heavier emphasis on being a visionary; later, emphasis should be place more on tactics related to finishing the project. • Projects fail when there is too much emphasis on tactical issues too early in the project. • Great teams are able to balance the two at each moment in the project.

21. Culture, by Descriptive Words and Phrases: Shared Sense of Urgency • Important that every one on team shares the same sense of urgency to complete the project. • If business people are more concerned about completion and developers are more concerned about the perfect architecture, failure will result. • A shared sense of urgency is also the most important factor in building eams. • It is NOT compatible personalities or team building exercises or even mutual respect that makes the bet teams; it is a shared goal or aggressive but achievable deadline that the team uses as a rallying cry for getting the project done.

22. Culture, by Descriptive Words and Phrases: Shared Sense of Highly Collaborative • Collaboration is a vital success factor in sustainable development. • Good teams are able to work together, embrace the differences between personalities and rules and stive for a successful project. • They recognize that there are clear rules for each of them to play. • Always there and should be done sub-consciously. • Must be done in person and not via email or voice mail, as much as possible because that is the most effective form of collaboration.

23. Culture, by Descriptive Words and Phrases: Complementary Talents and Skills • Great cultures recognize talents and skills from each other. • Too many companies are focused on skill alone and recruit only for skills. • But skills can be taught, whereas talent cannot. • Software development companies are perfect examples where people who are talented at complex problem solving make excellent programmers. • Yet, most ads still look for a certain number of years of experience programming in a particular language when what they should be looking for are people who are talented problem solvers.

24. Culture, by Descriptive Words and Phrases: Continually Improving and Learning • Continual improvement and learning is a vital element of sustainable development. • Great people and teams continually learn and refine their projects and how they approach projects.

25. Culture, by Descriptive Words and Phrases: Change Tolerant • Great teams understand that change is necessary and desirable. • They also understand change must sometimes be made in the face of conflicting or incomplete information. • Just because a decision is made at one time does not mean it cannot be changed or modified as new information becomes available. • So teams must be change tolerant.

26. Culture, by Descriptive Words and Phrases: Risk Aware • Risk is a common element in all projects. • Effective teams are always aware of risk and are able to differentiate between real and perceived risk and are not afraid to make decisions with the best information available in the face of possible risk. • Always looking for ways to reduce risk too.

27. Culture, by Descriptive Words and Phrases: Fun • Can’t always choose what you do, but you can choose how you do it. • Good people and teams recognize this and find ways to make work more fun for their co-workers and customers.