I don't know why I'm indulging your pedantry, and I think I'll stop after this, but what I'm reading from you is the following: Because he only failed at conti

I don't know why I'm indulging your pedantry, and I think I'll stop after this, but what I'm reading from you is the following: Because he only failed at continuously merging his code and writing tests, but didn't explicitly mention that there was no build server, then he didn't fail at continuous integration. He only failed at version control despite the fact that they were using CVS, were branching and merging appropriately, but were not doing so in the rapid fashion that became prevalent 10 years after version control. Additionally, because projects have managed to succeed without continuous integration at all, the rest of the original article that simply mentions his "questionable" CI failure is not even worth reading (but is certainly worth commenting on). Disregarding how closed-minded it is to dismiss both articles based on that single sentence, by implementing proper CI he would've covered all these "version control" issues anyway. I think it's fair to call that a CI failure, as it does fall under the blanket of good CI practices. Secondly, I think your bar for "success" is too low if you're willing to throw out "ticketing, automated deployment, and automated unit testing" but still call a project a success. I'd call that an inevitable clusterfuck regardless of how well it runs at the moment. Without these CI basics it's going to suck to maintain that system in just a few short years. I really, really hate dealing with systems that were built without these should-be-obvious basics.