On 10/18/2016 07:00 AM, interest-requ...@qt-project.org wrote:
I'm not even on board for TDD, because tests don't help you against
interlocking-issues, data races, etc. and are only of limited use
against many others like dangling pointers, subsequent memory
corruption, UI freezing, etc.
Tests can only prove the existence of bugs, not the absence (Linus
Torvalds doesn't even use debuggers, for the same reason)
At the end of the day, you need competent developers for complex tasks -
no programming language, no framework, no SDLC will ever change that.
I'm totally against TDD because everything about it is a myth _and_ because it is a massive waste of developer time. Marketing types like it because they can say "our software undergoes X-thousand tests with every check-in" but those tests prove nothing. I recently stumbled onto a "test" where a developer connected to the finished() signal of a post() but not the error(). No matter how the post() exited they were marking that chunk of data in the database as successfully sent. This was their interpretation of the "story" and it resulted in significant data loss because data on the device exists for only a limited number of days but the back end has many TB available.


Let us not forget what NASA's venture into faster-cheaper-splat taught the world about TDD.
http://edition.cnn.com/TECH/space/9909/30/mars.metric.02/
Both groups worked from their "stories" relentlessly testing their components without an overall architecture document.

There is _exactly_ one reason major companies are switching to Agile and it has nothing to do with the viability of the model. Agile is the only legal way to cheat accounting regulations.
http://www.fasb.org/summary/stsum86.shtml

====
This Statement specifies that costs incurred internally in creating a computer software product shall be charged to expense when incurred as research and development until technological feasibility has been established for the product. Technological feasibility is established upon completion of a detail program design or, in its absence, completion of a working model. Thereafter, all software production costs shall be capitalized and subsequently reported at the lower of unamortized cost or net realizable value. Capitalized costs are amortized based on current and future revenue for each product with an annual minimum equal to the straight-line amortization over the remaining estimated economic life of the product.
====

In years prior it was not uncommon to find major corporations with teams of 40+ developers, many of them consultants, developing systems for internal consumption. Large projects took (and still take) a minimum of 7 years to spec, develop, test, install and finally settle in. During that entire time the development costs were booked as assets. Now, under the 1985 accounting rules change, they have to deliver "something" to book as an asset. This means they skip the design because the detailed design required for a successful project of any real size cannot be done inside of a quarter. Instead they bang out absolutely useless chunks shifting the salaries of people not even remotely involved in the process into the Agile project so it can all be booked as an asset each quarter.

_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Reply via email to