https://speakerdeck.com/jacker 2014-06-20 06:01:53 -0400 One of the most challenging problems of developing business-oriented software is mis-communication. A disconnect between the business itself and the actual developers. Misunderstandings can be costly. Delivering the wrong thing following months of development can be devastating. How do we make sure we are building precisely what the business requires? How can we avoid wasting time building more than is needed (a.k.a gold plating). And finally, How can working from real examples of how a system should work can drive code that fulfils the real needs of the client. We need a more "business-aware" form of coding. Following BDD principles, starting from high-level scenarios, that broadly drive the application, down to specifications that drive the code, I will show how we can write software guided by examples; Examples which are derived from the very requirements of the business. One of the most challenging problems of developing business-oriented software is mis-communication. A disconnect between the business itself and the actual developers. Misunderstandings can be costly. Delivering the wrong thing following months of development can be devastating. How do we make sure we are building precisely what the business requires? How can we avoid wasting time building more than is needed (a.k.a gold plating). And finally, How can working from real examples of how a system should work can drive code that fulfils the real needs of the client. We need a more "business-aware" form of coding. Following BDD principles, starting from high-level scenarios, that broadly drive the application, down to specifications that drive the code, I will show how we can write software guided by examples; Examples which are derived from the very requirements of the business. Fri, 08 Jun 2018 00:00:00 -0400 https://speakerdeck.com/jacker/guided-by-examples https://speakerdeck.com/jacker/guided-by-examples A proposal for a workflow for developing AMD modules with a mockist (London School TDD) approach, in order help the developer avoid complexity and stay focused on the module under development rather than its collaborators. A proposal for a workflow for developing AMD modules with a mockist (London School TDD) approach, in order help the developer avoid complexity and stay focused on the module under development rather than its collaborators. Fri, 20 Jun 2014 00:00:00 -0400 https://speakerdeck.com/jacker/developing-amd-modules-mockist-style https://speakerdeck.com/jacker/developing-amd-modules-mockist-style