People are very creative. Using creativity, developers can code their way around all sorts of tricky situations. However, the arbitrary presumption that functional programming code guarantees a logical process entraps many people. The apparent interchangeability of the terms “programming code” and “logic” provides further evidence of this confusion. Code does indeed evaluate statements as true or false by employing logical operators such as IF, THEN, ELSE. Those evaluations execute or prevent specific actions. But simply coding a function that provides a desired result under certain initial conditions and inputs does not necessarily make that code entirely logical. Without any semantic considerations, programming remains logical only within the primal context of the machine manipulations of ones and zeroes. Maintaining logic at a higher level than “the machine” necessitates assimilating the semantics of the universe of discourse for the subject at hand - a programming version of speaking the “Queen’s English.” The expression of proper logic demands a meaningful semantic underpinning. A statement should evaluate to true when it conveys a level of accuracy within the semantics of the subject under study for the related process. Language, which in broad terms includes programming code, may deceive. Following language rules may create structures like “`Twas brillig, and the slithy toves did gyre and gimble in the wabe” or possibly, “The russet hippopotamus checked shiatsu against the papaya.” But the result is nonsensical rather than meaningful.

It rests squarely on the development staff shoulders to go the extra mile in supporting semantic integrity within the processes they define. Since the inherent and organized consistencies will not appear by any other magical means, then thought and toil must bring them to the development table. An enforced subject-area semantic consistency across functions and services creates artifacts more easily maintainable and more robust with warranted change.

As an example, assume a table is named “George” with two columns, A_Key, and A_Field. This table controls an online application’s display characteristics and functionality for varying groups engaging the application, where each group is associated with a different A_Key value. Initially, two groups deal with the application; Group 1 is customized to display a green background, Group 2 presents a blue background. The application code displays green whenever A_Field has a value of “Y” otherwise it defaults to a blue background (IF A_Field = “Y” THEN GREEN ELSE BLUE). As a later added application user, Group 3 wants the default music turned off. Because the developer utilizes the same A_Field column for this new variation, we now have three values: “Y”, null, and “K”. When populated with a “K” the blue background default is displayed, but the music is turned off (IF A_Field = “Y’ THEN GREEN ELSE IF A_Field = “K” THEN BLUE AND MUSIC_OFF ELSE BLUE). Such expansion, sadly, can continue. A more semantic approach might require a table named “Online_Control” with columns named Work_Group_ID, Background_Color_Cd, and Use_Music_Ind. The Background_Color_Cd contains background color and Use_Music_Ind holds a Y/N flag which designates whether to play the music or not. By splitting out separate attributes for the individual functions, rather than stewing multiple decision points together in the same pot, each function stands independently.

Both approaches provide code that functions properly. One approach employs realistic semantics reflecting the situation; the other approach simply provides some narrow-scoped functionality. And “narrow-scoped” is an apt depiction when more flexibility is needed, since additional “logic” only increases confusion in trying to understand what is happening. The approach that exclusively incorporates realistic semantics offers “easy” expansion - for instance, should one desire introducing new background colors, a natural expansion of code-values will suffice. The straightforward clarity of realistic semantics aids the development efforts. The uncomplicated tasks of naming conventions, table design standards, and various other data administration responsibilities enable the holy goals of “doing more with less” and building re-useable components. And when such standards entail the semantics of the whole organization, these standards then establish a foundation that allows business and IT personnel to speak together in meaningful ways.

About the Author

Todd Schraml is senior data architect and manager of ETL at Innovative Health Strategies, Inc. He can be reached at tschraml@ihsiq.com.