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
