Sadly, when one gets away from open source development and sees "enterprise" and/or "government" (a subset of "enterprise") development, what one finds is that everything is almost exclusively "deadline date" driven. The PM's and/or upper level managers pick dates for deliveries (seemingly often without regard to ability to achieve deliverable X by date Y) at the start of any dev. cycle. The end result is the low level managers get pressured to "meet the date" and so the developers get pressured to go faster to "meet the date" with the result that often the deliverable X "meets the date" but is very buggy, hacky, ugly, hard to further extend, etc.
And then, of course, for the PM's and upper management layers, the fact that their project "met the date" is what is measured and congratulated all around. The product could be a stinking pile of XXXX, but "it met the date", so they get their kudo's, their bonuses, and the devs. and users are left with "stinking pile of XXXX".
As a PM I remember the halcyon days when my management would actually request a formal estimate and I would then work with delivery teams to calculate an answer and then add the traditional 50 to 100 pc buffer because I knew they were full of crap/I kept a personal record of their history of estimate vs reality. Nowadays management are in to top down planning so they don't ask for estimates, they don't add realistic buffers so they over promise with one hand and underestimate with the other. Seems to be a trend where everyone thinks they know how to do a PM's job.
Yeah but on the other side if you just let engineers do everything "the right way", we'll never deliver anything because there's always a "better" way to do it. I agree that "success-based planning" is ultra bad, but engineering needs to be held to some level of accountability.
Or maybe I just blame capitalism, haha. No deadlines! I do this because I like it!
Yes, they should have. adding tests long after the fact is next to impossible because, when you spend a long time not adding them, your codebase tends to degenerate into an untestable mess. One of the key benefits of strict TDD is that you feel the pain of testing your code before you write it, so your code is testable from the start.
And then, of course, for the PM's and upper management layers, the fact that their project "met the date" is what is measured and congratulated all around. The product could be a stinking pile of XXXX, but "it met the date", so they get their kudo's, their bonuses, and the devs. and users are left with "stinking pile of XXXX".