Lean Software Systems Engineering for Developers: Managing Requirements, Complexity, Teams, and Change Like a Champ

Table of Contents
About the Authors
About the Technical Reviewer
Acknowledgments
Foreword
Introduction
Chapter 1: Focusing on Software Development Outcomes Instead of Outputs
	Introduction
	Software Engineering vs. Software Development
		Coding Is Not Software Engineering
		Defining Software Engineering
	Why Does Software Engineering Matter?
	Errors in Judgment
	Managing the Dimensions of Complexity in Software Development
		Objective Complexity
		Requirements Complexity
		Solution Complexity
		Agility Comes from Managing Both Requirements and Solution Complexity
	Our Responsibility
	A Path Forward
	Summary
	Key Takeaways
Chapter 2: Gaining a Shared Understanding Throughout the Project
	Introduction
	Sources of Defects and Rework
	The Danger of Incomplete Pictures
	Why Developing a Shared Understanding Early Is Important
		Adding Structured Processes
	Leveraging Lean Approaches to Backlog Development
		Journey Mapping and Story Mapping
		Using Critical Thought to Decompose Requirements
			How Other Engineers Tackle Big Problems
			Estimation Scales
			Estimating Our “Submit Order” Story
	Summary
	Key Takeaways
Chapter 3: Validation of User Experience
	Introduction
	The Evolution of UI Design
	Challenges with Modern UI Design
		Scenario 1: Technology
			Constraints of the Modern Web Frameworks
			Business Logic Bleeding into the UI Layer
		Scenario 2: Process
			Missing Artifacts
			No Accommodation for UI Design Time
			Failure to Communicate
	Strategy for Effective UI Validation
		Generate Good Requirements
		Develop Acceptance Criteria
		Develop Screen Flows and Wireframes
		Review the Preliminary UI Design
		Develop Mockups
		Review the Mockups
		Design the UI Components
		Define the Client/Server Interactions
		Build the UI Using Mock Data
		Review the Working UI
		Integrate Working UI with the Real Back End
	Summary
	Key Takeaways
Chapter 4: Designing Software Systems That Age Well and Adapt to Change
	Introduction
	Reality Check
	Errors in Judgment Revisited
	Case Study: Notification Subsystem
		Change 1: Supplier Order Email
		Change 2: Order Shipped Notices
		Change 3: New SMTP Service
		Change 4: Order Notices for Shipping
		Change 5: Abandoned Cart Notices
		Change 6: The Change That Forces the Redesign Conversations
		The Redesign
		What Critical Thought Might Have Uncovered
		Tactical vs. Strategic Development
		Case Study Wrap-Up: Common Errors in Judgment
			Lack of a Design Identity and a Defined/Disciplined Methodology
			Decomposing Systems Based upon Requirements Instead of Change
			Thinking Tactically Instead of Strategically
			Lack of Understanding of Core Concepts and Principles and the Impacts of Design Decision Trade-offs
			Allowing Material Design Decisions to Be Made by Anyone
			Stagnant Mental Models for Software Systems
	Core Concepts and Principles of Modern System Design
		Coupling and Cohesion
		Information Hiding
			Trade-offs Are the Norm
			Information Hiding Hierarchies
	Why Designing for Change Is Important
		Design Stamina
			Increased Comprehensibility
			Meeting the Demands of Modern Applications and Business Agility
	Managing Complexity in Other Systems
	Choosing a Design Methodology
	Summary
	Key Takeaways
Chapter 5: Developers “Falling into the Pit of Success”
	Introduction
	Reality Check
	A Developer’s Life
		A Bad Week
		Sound Familiar?
	Creating a Pit of Success for Developers
		Positive/Can-Do Team Attitude
		Ensuring Requirements and Acceptance Criteria Are Understood
			What Is My Understanding of the Requirements? What Is the Primary Goal or Objective?
			What Are the Secondary Goals/Objectives?
			What Are the Known Design Constraints?
			What Are the Acceptance Criteria for the Solution (Including Non-functional)?
			What Assumptions Am I Making About These Requirements and the System?
			What Are the Unknowns? (i.e., What Information Is Not Currently Available?)
			What Are the Trade-offs I Am Deliberately Making?
			What Areas/Features Are Most Likely to Change over Time?
			What Are Anticipated/Possible Failure Scenarios, and How Should They Be Handled?
			Are There Any Special Considerations Related to Security?
			What Are the Existing Areas Impacted?
			How Will the Design/Architecture Need to Change?
			How Can I Encapsulate Current and Future Change?
			How Should I Test and Validate the System?
			What Risks Am I Aware Of?
			What Concerns Do I Have?
			What Are the Specific Steps to Implemention, and What Is Their Level of Effort?
		UI Design Artifacts Before Development
		Design Identity
			Service-Based Systems
		Reviewing and Verifying the Design
		Testability
			Deciding What to Unit Test
		Isolating Developer Environments
		Maker Schedule
		Mentor
		Establishing Clear Developer Expectations
	Pit of Success Checklist
	Summary
	Key Takeaways
Chapter 6: Institutionalized Quality
	Introduction
	Reality Check
		Moving Fast vs. Maintaining a Rapid Pace
	Toward an Integrated, Layered View
		Quality Targets
			Defect Detection Rate
			Percentage of Rework
		Quality Mindset
	Quality Practices Review
		During Requirements Analysis
			Shared Understanding
			Validation of the UI
		During Design
			Validation of the UI
			Designing Systems That Age Well
			Designing How to Execute the Project
		During Development
			Establishing Clear Developer Expectations
			Reviewing the Requirements and Design Artifacts
			Ensuring Requirements and Acceptance Criteria Are Understood
			Enabling a Testable System
			Implementing Continuous Integration with Automated Integration and Unit Tests
			Using Structured Code Reviews and Pull Requests
				Pull Request Code Review Checklist
					Review Before Submitting
					Testing
					Architecture
					General Code Review
					New Projects
					Database Changes
					UI Changes
					Cloud Architecture Changes
		During Acceptance Testing and QA Testing
	Summary
	Key Takeaways
Chapter 7: The Role of Chief Engineer
	Introduction
	Revisiting the Football Analogy
	Chief Engineer
		Responsibilities of a Chief Engineer
			Maintaining the Big Picture
			Maintaining Conceptual Integrity
			Seeing Around Corners
			Coaching and Mentoring
			Building Trusted Relationships
			Being a Proactive Communicator
			Ensuring Adequate Testing
			Achieving Technical Success of the System
	Summary
	Key Takeaways
Chapter 8: Bringing It All Together – Creating an Action Plan
	Introduction
	What It Will Mean for Software Development to Be an Engineering Discipline
	Starting Your Transformation
		Understanding the Maturity of Your Team
		Lightweight Organizational Maturity Assessment
			Leadership Roles
			Managing Requirements Complexity
			Solution Complexity
			Operational Effectiveness
		The Steps Toward Transformation
			Secure Your Platform
			Minimize Uncertainty
			Automate Your Builds
			Protect Your Developer Time
			Maintain Conceptual Integrity
			Improve Your Productivity by Improving Quality
			Reduce Rework
			Improve Predictability and Visibility of Results
	Achieving the Ultimate “-ility”… Funability
		What Contributes to Funability
		Frequent Delivery of Value to Customers
		Being Part of a Team
		Maintainability of Systems
		Effective Management of Technical Debt
		Consistent Quality of Product Releases
		Productivity and Efficiency of the Developers
		Sound Software Design
		Now What?
	Key Takeaways
Index