Well this is the state of the industry. There certainly are companies with well-written, well-documented, well-tested code but they don't hire because they don't need to. Their code is easy to change and maintain, so why pay more people? This is all most project managers know - absolutely never improve the process or the tools, just throw more people at the problem, so that's why you were there.
Don't (unless you really don't like writing software).
The answer I've come up with is either become a project manager (not working out so far, nobody wants to hire a PM without PM experience here, no matter the certifications), or start your own company (which might be the right answer in your case).
To be honest, I think both documentation and test cases are overrated, I do believe in lots of user testing and feedback, which is the most important thing (and that's why I believe any methodology that encourages frequent user feedback is a good thing).
What I'm writing about applies for the usual business or customer facing apps, I don't know about other fields (maybe for scientifical or medical or whatever apps it's a whole different story).
All the guys crying about the prevalence of TDD are the ones who are lucky enough to live in a tech hub from a developed country. In my area I'm the only one who knows about TDD/BDD.
You want to know how testing is done here?
- 80% of projects have no testing whatsoever
- 20% are manually tested by students paid with 3$/hour
Unlike others, I would love to be surrounded by "TDD zealots or fanatics".
You would hate your life if you were surrounded by TDD fanatics?
Would you love your life if you had to change huge applications with 100k+ LOC without any kind of testing and if anything breaks at the client, it's your fault?
TDD didn't appear out of the void because some wankers want to deride everyone else, it's the ONLY WAY to have tests in the business world because if the features are developed first, the business guys will say "let's skip the tests to cut the costs".
There's a balance.
>it's the ONLY WAY to have tests in the business world
Perhaps in some organizations. I feel sorry if you have to work in such an environment. My company recognizes the value of testing-we have 15,000 acceptance tests and unit tests, and we do TDD perhaps 20% of the time.
I worked at a bank where there were 0 unit tests or acceptance tests. Just some half-assed QA guy going through toy scenarios and pushing the 'approve' button. That's not where I want to be (therefore I quit), but I also don't want to be in an environment where people scream and call me an infidel if I don't do TDD.
I'm more of a pragmatist. I think one size fits all is a bad strategy, and different projects have different needs.
There is nothing I hate more than working with people who passionately believe that there is only one true way to do something (like testing) and believe the process and 'craft' is more important than other factors like, say, delivering business value.
There is a lot between your extremes of TDD and no tests at all. And when I hear a developer say some methodology is the ONLY WAY I find it's best to run, not walk.
I'm not saying TDD is the only way to write code, I'm saying TDD is the only way to make sure that you will have minimal automated testing.
About your condescending remarks about delivering business value, I'd like to see you delivering business value while working with 10 other people on a tightly coupled 100k+ LOC application with no tests. Do that, then I might take you seriously when you say that the craft and process don't matter.
EDIT: Here's how business is done in some parts of the world. I give you the crash tests for the world's cheapest car: https://www.youtube.com/watch?v=RUdKf0FQgEg .Businessmen will gladly endanger human lives in the name of cutting costs, do you actually think they will allow any kind of software testing?
> I'm not saying TDD is the only way to write code, I'm saying TDD is the only way to make sure that you will have minimal automated testing.
We'll have to disagree there. It's a fine way. There is rarely just one true way however.
> About your condescending remarks about delivering business value, I'd like to see you delivering business value while working with 10 other people on a tightly coupled 100k+ LOC application with no tests.
I, sadly, do this every day. It sucks.
> I might take you seriously when you say that the craft and process don't matter.
I never said they don't matter.
I'm advocating not taking a black and white view of things, which you seem to be doing. There are more options out there than 100% TDD 100% of the time or skipping testing completely...
Oh, yes, it's great to be a workhorse developer. You don't get any opportunities to use new technologies and improve your skills at work so you have a choice: program at home after work and in weekends or become useless in a few years and get out of the field or move into management if you're lucky.
It's really fun to make the first choice, because you either give up socializing and live a hollow life focused exclusively on programming, or you don't have time for physical exercises, cooking and eating real food(not junk) and other human routines that keep you healthy and you die at 40.
But never worry, because right before you'll leave this world you'll be able to say with immeasurable pride: "I've made someone else rich!".
Don't be stupid and care about interesting work and improving yourselves and especially don't boast about it because you make the workhorses feel bad(and FSM-forbid, even open their eyes). Shut up and keep your heads down because it will all be over soon.
