Comments by "" (@grokitall) on "NDC Conferences" channel.

  1. just do it right the first time is the best approach, but only when you have precise knowledge of the inputs, outputs, and the transforms you need to use in order to get from one to the other, and what other constraints like speed and memory usage apply. unfortunately while this may work for things like low level drivers, over 60% of projects don't know this stuff until you try and write it, and find out it was exactly what the customer did not want. tdd and ci work by having the developer write functional unit and integration regression tests to determine if the developer wrote what they thought was needed. acceptance tests are typically written when it is presented to the customer to confirm that the developer actually had a clue what the customer requirements were, and as the customer does not know this on 60% of projects, it cannot be done at tdd and ci time. instead, they are written when the customer is available, and then executed as part of the deployment pipeline which checks that it provides both the functional and non functional aspects needed by the customer. a few of these tests can be added to the ci system, but mostly they do a different job. tdd creates relatively clean testable code with tests that you know can fail. ci takes these tests and highlights any code which no longer meets the executable specification provided by the tests and thus does not do what was needed. cd and acceptance tests deal with how it works, is it fast enough, uses a small enough set of resources, anything which should stop you deploying the code. monitoring and chaos engineering checks things that can only be discovered in production, ie how does it scale under load.
    1