conversations on agile technical practices and investments

Key ideas practice TDD as a design technique and not as a testing technique Software development as a learning process. Expose uncertainly early by testing our assumption as early as possible we use mock objects to identify the essential interactions between modules/objects. This leads to more effective abstractions, which reduces the cost of changing the cost safely over time. Stub queries; expect actions??? Write code that depends as little as possible on its context. programming by intention Test-Driven Development (TDD) and Quality Software development as a learning process. The best approach a team can take is to use empirical feedback to learn about the system and its use and then apply it back to the system. Development is incremental and iterative. Incremental development builds a system feature by feature. Each feature is implemented as an end-to-end slice. As a result, the system is continuously integrated and ready for deployment. A system is deployable when the acceptance t

The lowest effective dosage the smallest dose that will deliver your intended result to eliminate stored fat , perform a bare minimum to activate a fat-loss cascade of particular hormones to build muscle in tiny or significant amounts, complete the bare minimum to activate local (muscle-specific) and systemic (hormonal) development processes Physical recreation is not exercise. Exercising involves performing MED to produce a targeted change . Ground Zero No Tracking = No awareness = No behavioural change tracking the ratio of body composition and not weight. Ask yourself, " How much is a useful muscle, and how much is useful fat? " four principles of failure proofing make it conscious , beware in real-time and not after the fact. For example, taking a picture of what you're about to eat will make you think twice. Make it a game , measurement = motivation. Seeing any changes in numbers creates a positive feedback loop to make it competitive. The potential loss is a more f

DDD overview anatomy of domain-driven design Putting the model to work Domain-Driven Design is an approach to the development of complex software in which we: Focus on the core domain Explore the models in a creative collaboration of domain practitioners speak a ubiquitous language within an explicitly bounded context. Bounded Context Explicitly define the context within which a model applies. Explicitly set boundaries in team organization, usage within specific application parts, and physical manifestations such as code bases and database schemas. Apply continuous integration to keep the model concepts and terms strictly consistent within these bounds, but don't be distracted or confused by issues outside.  Ubiquitous Language Use the model as the backbone of a language. Then, commit the team to exercise that language relentlessly in all communication within the team and in the code.   Use the same language in diagrams, writing, and speech within a bounded context. Recognize that