# Does the "continuous" in Continuous Integration come from continuous mathematics?

I started working through a textbook and Youtube series on discrete mathematics at the end of last year, and I haven’t gotten very far yet, but I’ve really enjoyed it. Discrete math is the category of mathematics that is the root of much computer science, specifically programming language theory (I think). Things like set theory, formal logic and … well, that’s all I know about so far.

Discrete math is distinct from continuous math, also phrased as discrete vs. continuous data. Discrete data is in specific increments, or is “countable”: 1,2,3,4. Continuous data is a spectrum, or “uncountable”: all of the values between 1 and 4, including 1.2232424234 and 3.9. This is a good Youtube video about it.

At work, I’ve started looking into automating processes for our design system repository with Githooks and a tool for generating a changelog. From my understanding, that is considered CI/CD (continuous integration/continuous delivery).

That got me to thinking…does the word *continuous* in CI/CD indicate the concepts in *continuous* mathematics and data? It’s kind of the same thing – in continuous integration, you don’t count how many times code is integrated into a repository. Discrete integration would be if you did deployments once per day. Was the person who coined the phrase *continuous* integration thinking about continuous mathematics when they needed a name?

According to Wikipedia, that person is Grady Booch (he also created Unified Modeling Language! I want that for design systems) and he is very much still alive and doing super interesting things – maybe I’ll ask him.

This is yet another example of – at least for me, but I think for all humans – how powerful for learning it is to see the concepts from one area intersect with those in another area, and have the epiphany, “Wait…those things are the *same!* I already understand this!” This is why I love learning about computer science and, now, a bit of mathematics. There are so many intersections to be discovered, and therefore little epiphanies to be had, in my day to day work developing software.