- 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
-
Applies when:
- 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.
- Complimentary
-
Theory of Constraints vs “Lean”
- Release Strategies and Versioning
- Effective Organizational Culture
- Continuous Learning
- DevOps
Software Engineering as a Team Focus
-
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.