[Interest] What don't you like about Qt?

Roland Hughes roland at logikalsolutions.com
Tue Oct 18 14:46:35 CEST 2016


On 10/18/2016 07:00 AM, interest-request at 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.




More information about the Interest mailing list