| No it wasn't! That's the whole point. What some people consider to be "good engineering" is a different set of standards, a different set of qualifiers. Let's go back to 2012. I was yet again doing web stuff. We had this hodgepodge of jasmine, junit, eslint and selenium and couldn't commit unless it all passed But the tests broke more then the code itself, because it was <far more complicated then the thing being tested>. So more time was spent on fixing and babysitting the tests then writing the damn software. Alas, we finally released and it totally completely bombed. Why? Because those test suites don't care if something "feels" clunky or "looks" wrong ...The machine responded to the interface in machine time, it didn't actually test human time, which was the only thing that mattered. We should have relied on human dogfooding, like the business books say to do. I got arrogantly laughed at for suggesting it, multiple times; that simply wasn't "engineering" to this team. Now of course tests are valuable, sometimes. But "sometimes", that's the important thing. Understanding when to make that call is actually important. When, where, what, why, and how - not just important for journalists. But instead, like some 18th century royal court disconnected from reality, we did ceremony. So we wrote tests, most of them bullshit. One of the tests was essentially: "Does this image on the page load from s3?" At least that one usually passed. Except when AWS was down or our internet went out: "I guess we can't work today, the does_image_load_from_s3 test is preventing the commit." They were a waste of time and got in the way of actual work. But we HAD to have them, we MUST, right? Nonsense. I'm convinced the tests were there because "doing it right" was about virtue signaling. So we built a salary defending potempkin village composed of pure thought stuff. I imagine it all like a catholic mass: Men in robes walk around, ring bells, and use special boxes to wash their hands with special cloths; it's all very important if you go to church, but that's the point, it's praxis and faith: we were coding from plato's cave, creating intricate shadows of reality representing actual work. Symbols passing as tools: like Dumbo fetishizing the feather and being oh so worried when it falls, everything passed the most sophisticated testing I had ever seen yet the program still crashed in the user's hands almost every time. All that work was mere ceremony. Understanding how modern computing speeds and vc capital has allowed people to be wrapped up in their own bullshit, call it programming and get away with it, is a major insight into why technology sucks today. It's not just you, everyone agrees. It's lame now. |
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.