- Empirical Studies Show Test Driven Development Improves Quality – brief summary of two researche papers comparing TDD/non-TDD, one paper with 1 case study from IBM and 3 from Microsoft (get PDF; conclusion: The pre-release defect density of the four products, measured as defects per thousand lines of code, decreased between 40% and 90% relative to the projects that did not use TDD. The teams’ management reported subjectively a 15–35% increase in initial development time for the teams using TDD, though the teams agreed that this was offset by reduced maintenance costs.), one older summarizing 13 case studies (conclusion: TDD seems to improve software quality, […] there were indications that TDD does not necessarily decrease the developer productivity or extend the project leadtimes: In some cases, significant productivity improvements were achieved […] However, in both of those studies the quality was improved.).
- Quantum computers are reality: World’s first commercial quantum computer sold to Lockheed Martin – this means that hard and NP-hard problems become solvable or at least much easier to solve (this means incredibly lot, just think about optimization problems, scientific computations and simulations, …) and that current security measures are becoming obsolete. It has “only” 128 qubits, which sounds small but is a big thing (competitive regime for quantum comp. is about 100).
- Fit co-author says acceptance testing costs more then it is worth (i.e. there are better alternatives) – it’s always good to learn from failures; the author, James Shore, has several pleas against A.T.: “[..] customers (a) weren’t interested in doing that, and (b) often couldn’t understand and didn’t trust tests that were written by others. [..] Furthermore, acceptance testing tools are almost invariably used to create end-to-end integration tests, which are slow and brittle. Fit works best for targeted tests that describe the domain, but that’s not how it’s used. Also, tools like Fit [JH: which is based on HTML] don’t work with refactoring tools.“, summarized: non-participation of customers and maintenance burden. Gojko Adzic opposes that we can avoid the pitfalls while retaining the benefits – I guess his Specification by Example book is quite lot about this, as well as the last month mentioned post Top 10 reasons why teams fail with AT
Unit tests, [..], are so coupled to the low-level API that it is often hard for the developers to avoid the trap of proving that the solution works in a particular way, rather than asserting that is solves a particular problem.
– from the book Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, published in an InformIT article