[kovac]

What's strange is I can also give you examples of how testing code bugs that had been there for more than 3 years (security related mind you) and a company whose release branch didn't compile on my day one because a guy who doesn't believe in any software development process and committed directly to the release branch.

I don't mean, dogmatically follow unit tests (actually my statement wasn't predicated on unit tests). If you have a better approach that can validate the software is correct then I'm all ears. If you have a better collaboration tool than git, I'd be happy to try it. With all due respect, what I can't do is take your word for it that you can build software that works (covers all functional and non functional specs), and they continue to work as more code is added, and is worked on by more than one or two developers, and that you can continue to validate and roll out more software over the years even when the original developers aren't around. It's difficult, costly. It can work, it's just not the best way. The industry will evolve and come up with better tools and processes than we have today as we did before yesterday. Only thing I took from the couple examples you gave is that you've had the misfortune of working in some terrible teams. Though I still don't see how you'd be better off without the rest of the usual practices we have today. The guys who couldn't code the tests, I can't imagine them building a non trivial software well either. I'm not defending any one process. I just don't agree that we don't need any process, and that we should just write code that (seems to) works.

[ratww]

The thing that the parent poster is trying to point out is that our fancy programmer tools, processes, ceremonies and tests are worse than useless if they get in the way of actual work and make you miserable and unproductive. People leave jobs because of this. People burn out because of this. Companies lose money because of lack of productivity.

This is what this whole thread is about.

If tests are "taking the fun away", like you said, they're shit. Simple as that. Tests are a productivity tool, they're supposed to make your job easier by providing faster feedback. If manual test is faster than automated test, your automated tests are shit. If they're causing developers to write the bare minimum of tests it will only generate a false sense of security. This is even worse than saying "ok we don't have tests, let's be careful and test manually".

It's like that stupid saying that bad documentation is "better than nothing". It's funny how people change their minds when they spend four hours or more on a stupid rabbit hole because of outdated documentation.

On the other hand, one of the best jobs I ever had was maintaining shitty web apps written without source control, tests, documentation, patterns. Thousands of lines of code. Some of them didn't even have source code: I had to decompile the production server DLLs. I don't have any coder friend that got burned out by "bad code". Not having autonomy to improve the bad code, on the other hand, made a lot of them change jobs.