As I write this piece, winter has suddenly appeared, a perfect day to reflect and (hopefully) to compose. The field of computing appears to be in ascent as developers figure out novel, often inspired, ways to exploit its potential. These "cool features" (e.g., natural language processing, word prediction) are at the same time empowering. Accessibility and universal design have each been a goal, and we can truly witness progress towards these goals in the devices we use.
I use my "app-phone" (a.k.a., smart-phone) hourly, as the blending of research in usability engineering, mobile computing, machine learning, client-server, and dependability are now available in my pocket. I am also amazed at the inexpensive cost relative to the same computing power from early in my career. These are examples of "cool applications," the result of many years of projects that realized a gap and sought to bridge that gap. Many of these projects, I assume, are not necessarily examples of where college-level mathematics impacts software development. This column has already presented evidence that not all software development needs math as a tool , even the cool ones. In preparation for this piece, I discovered that the acronym CRUD (create, read, update, delete) also has a somewhat pejorative implication, for software applications that maintain persistent storage (as in forms) and not always the most challenging code to compose.
I made this discovery while reading , a blog post that could have served as a Math Counts column for software developers. The post asked almost the same question as previously in ; namely, why do application developers study mathematics as a requirement for computer science? Many developers need little more than arithmetic to complete most programming. And that's when the term CRUD development arose to describe simple, almost rote, coding that simply moves data around and (seemingly) requires no math. It also appears that much development presently involves websites. Alternatively, the more interesting software projects did need the ability to apply math. I interpreted this last observation more to imply mathematical maturity than simply math skills .
However, I must proceed with caution here. As a thoughtful reviewer recently reminded me, mathematics is a very broad term, and a certain degree of competence is often required, or at least helpful, with specific mathematical concepts and applications . For example, understanding the role of the remainder operator can help developers express correct and clean code (i.e., without the need to express this operator with its mathematical definition). This observation is true for all types of applications, not just the cool ones.
Still, I think the author of  is onto something, and he lists a nice series of examples where an understanding of mathematical concepts is useful, examples presented in this piece earlier as "cool features." While he did not deal with the question of when or how to get this understanding, he did make a novel observation that I will try to share here.
The Law of the Instrument (a.k.a., Maslow's Hammer ) suggests that a person with a specific tool (e.g., a hammer) will then adjust any problem encountered in such a way as to use that same tool (i.e., as a nail). This law is attributed to Abraham Maslow, though there is evidence that Abraham Kaplan suggested it prior to Maslow . In any event, the idea is the same; specifically, that the proposed solution to a problem is often influenced by the tool(s) available at hand. Sorkin  sees the phenomenon of programmers not using mathematics in their work as a sort of "inside out"–or dare I say contrapositive–version of Maslow's Hammer. In other words, if I am not comfortable with a tool, then I select problems that I can solve without that tool. There does appear to be substantial need for software that can be developed with–again, seemingly–little to no math, so perhaps programmers are actively or subconsciously avoiding mathematics in their careers.
Yes, this observation does not address undergraduate curriculum, but there have been reports that certain topics in mathematics seem to be difficult for certain students from computer science programs . We may be still talking about developers with "math avoidance" who survived the mathematics requirements in the undergraduate computer science program (or perhaps "went rogue" and learned to code on their own or at a coding academy!).
We now return to undergraduate computing education. If the above description of events holds to some degree, then I am more inspired to promote a "just enough" approach to introducing mathematics to a computer science student (i.e., future software developers) so they can have more choices throughout their career. And as seen in the discussion of maturity , they will still need to review the math as they encounter it in their career, but I hope we can begin the process sooner than later.
But I must proceed with care. I do not want to fall victim to the Law of the Instrument myself, suggesting that every programmer must be an expert in all of mathematics. I am comfortable suggesting that proficiency with as much of mathematics as possible will provide a rich set of tools for the budding computing professional. This proficiency should facilitate a more engaging, perhaps even a "cooler" career.
6. Sorkin, A. You don't need math skills to be a good developer but you do need them to be a great one; http://www.skorks.com/2010/03/you-dont-need-math-skills-to-be-a-good-developer-but-you-do-need-them-to-be-a-great-one/ Accessed on 2017 Feb 6.
John P. Dougherty
Department of Computer Science
370 Lancaster Avenue
Haverford, Pennsylvania 19041 USA
Copyright held by author.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2017 ACM, Inc.Contents available in PDF
View Full Citation and Bibliometrics in the ACM DL.
To comment you must create or log in with your ACM account.