I'm curious your experience with TDD and other hip programming approaches? Because I've been long wondering if "web programmers are generally more vocal" has a lot to do with their popularity.
(Disclaimer: I love automated tests, particularly integration tests, and use them wherever it seems practical. But I cannot imagine developing the software I develop with a "unit tests first" strategy...)
My experience, while nowhere close to being representative of the aviation industry at large, has been that large industrial companies are somewhat schizophrenic in this regard.
I often find myself appreciating, for example, the care that somebody put into their automated build tools so that my unexpected corner case (which I originally expected to break things) actually worked the first time without a hiccup. Yet later in the same day I will be cursing the awful, terribly broken two decade old version control system that the same company is paying enormous sums of money to license.
TDD is one of the approaches that I advocate for often, though not the extreme versions that some people advocate for. Some people get it, while others think it's more efficient to wait until the last few days of a waterfall(ish) process before running comprehensive tests (because "testing costs money"). The panic that ensues when they discover a major problem days before a big deadline is never very pretty.
I'd kill for a TDD framework in the tools I use. While you label many things as "hip programming" my industry is several years behind the fast paced methods of more popular platforms like the web.
For the record, TDD was taught in my university education course as a pretty core testing methodology. The reasoning behind it is sound as it really helps you program to contract and forces the programmer/engineer/manager/whatever to make critical thinking decisions ahead of time. Working "On the fly" isn't always practical.
Hard to get over just how behind automation is. The big scada platform we use is 'disruptive' (ie cheaper and better than the entrenched players) yet they think we should be happy that the brand new version finally supports half-assed, internal version control.
I worked at a company with both a big web application and a bunch of hardware and firmware development. We showed the hardware and firmware developers our integration tests using cucumber, and after about a year they were test driving big swaths of their process using cucumber. (And they were better at it than we were.) My point being: with some work it can be possible to integrate the "hip" tools into your process, and sometimes it even makes sense and works ok!
(Disclaimer: I love automated tests, particularly integration tests, and use them wherever it seems practical. But I cannot imagine developing the software I develop with a "unit tests first" strategy...)