- Software Engineering as a Discipline
- Phoenix Project: 3 Ways: Solve the “getting code into production” problem
- Unicorn Project: 5 Ideals: Solve the “empower teams with data” problem
- Related to OODA loop
Plus/Minus/Interesting is a way of fostering creative thinking
- The concept of breaking people out of cognitive biases such as binary thinking is inherent in all of these
Overall goal seems to be “let smart people be smart, let people do good things, and foster both as well as you can”
- But not always… This might be the overall goal of Flow vs “in general”
O-Ring Theory suggests that it’s important to match qualities.
- Goes along with “subordinate everything to above decision”
- Hiring rockstar developer doesn’t fix problems if problems are elsewhere.
- Same as Amdahl’s Law
- Production depends on completing a series of tasks
- Failure or quality reduction of any one task reduces the value of the entire product
- You can’t substitute quantity for quality
Theory of Constraints
Theory of Constraints vs “Lean”
- ToC identifies constraints and pushes past them
- Lean is about improving flow, minimizing waste, etc.
- Theory of Constraints vs “Lean”
- Release Strategies and Versioning
- Effective Organizational Culture
- Continuous Learning
Software Engineering as a Discipline
Software engineering is in a sad state of affairs currently and needs to develop from its current ad-hoc and informal procedure into one that embraces both sides of Computer Science: Theory of Computation and Theory of Systems To do so requires Software Engineering as a Team Focus, and Software Delivery; ultimately culiminating in something that I’m currently calling Continuous Compliance.