Team. Hopefully, the past few weeks have been productive for you. Our last post summarized how CABOOSE simplifies the web application development process and associates a single method, module, function, or subroutine with a web page concern. Such an approach prevents web application developers from building one large, unwieldy monolithic routine for processing a response.
Around 2013 during an employment interview at a company in the top 25% of the Fortune 500, the hiring manager mentioned her frustration with the number of her engineers who wrote monolithic main methods in JAVA. These "Big Bang" applications are not easily verified or maintained and defy all of the fundamental teachings in elementary first-year computing courses. They arise from haste, a lack of discipline, and limited training. As a result of the demand for development professionals in the 1980s and 1990s, many IT workers entered the field with only a year's technical training and a certificate of completion. They could write a COBOL program and were capable of reasoning about business processes.
Few knew the rudiments of algorithmic analysis which most college computing majors learned in their freshman year in the 1980s and some high school students of computing learn now. Most of these "certificate" developers had not had the learning experiences of a college computing student. This was not a reflection of their natural intelligence. Many were exceptionally bright. They simply had not acquired many of the skills of majors in computing at that time. As such, the IT world has experienced and is still experiencing some dysfunctional development practices inherited from a era when IT managers simply needed "warm-bodies" on their teams for billing purposes.
Case in point, in the early 1990s, while working as a COBOL programmer with only a freshman computing elective in Pascal and COBOL training, management requested an estimate for the completion of a "controlled-break" program. After a few seconds of assessing the requirements, the response was one person-hour since some of us are only capable of hunting and pecking. The manger smiled and said that she usual gives her senior people "one whole day" for a report and her junior staff "a couple of days". Sensing inexperience, she smiled and said let me know where you are in an hour.
Thirty minutes of coding, fifteen minutes of verification, plus a nested loop and well-placed conditional later, this inexperienced, young coder was done. Arriving fifteen minutes early at the manager's desk with a "green-bar" printout of the report, she simply smiled and said "let me see what you have". She desk-checked the details lines through the first few break totals and the grand total. Looking stunned, she said, "This looks correct!". And she asked if she could see the source listing which contained less that thirty lines of processing instructions. She said "No one around here does anything this fancy."
This "success" resulted in many a headache after being alienated by some of the senior staff who had "old school" training in computing. This whippersnapper with a semester of university training in Pascal and structured programming plus a COBOL class from a junior college had caused a stir in the department by using a COBOL PERFORM statement in its loop format. Most of the staff was still using this statement as an alias for a GOTO which is one of its capabilities. This is simply how they were trained. The pattern of their standard solution for a "controlled-break" report required a number of "goto-style" PERFORMs which transferred control between paragraphs which are the equivalent of compound-statements in JAVA. After being chastised by senior staff for writing such a program, being told the a professional COBOL programmer writes these programs a certain way, and realizing that this simple departure from workplace norms could cost a job, all future reports were in that "old-school" style which has its roots in assembly language programming.
In summary, old traditions resist fading away, we also view new concepts through the lens of past experiences, and societal pressures often stifle advancement. Many of the first COBOL developers where experienced assembly language coders. So, they wrote and taught COBOL in an assembly language style which rest upon the use of large monolithic programs with branching commands that redirect the flow of the control abruptly and sometimes unexpectedly. Although COBOL allows for PERFORM statements that behave like a for, do-while, or while loop plus link-edited subroutines which promote a better partitioning of concerns and serve the purpose of a method, most COBOL programmers simply wrote large single module program with numerous "goto-style" PERFORMS. Although COBOL has numerous standards, 68, 74, 85, and etc., plus has kept pace with advances in computing such as object-orientation, most of it developers are mired in old practices. And, many of these COBOLers are still around and coding the "new-COBOL" with the monolithic approach when they can get away with it. It is simply a comfortable dysfunction for them.
CABOOSE lets these developers have the best of both worlds since they can write a single method for handling each dynamic concern within a page. This instead of a single method for handling the entire page. This approach facilitates better engineering practices by helping developers identify and isolate the code associated with concerns at a single point of modification. This should be a comfortable notion for both the "old-school" COBOL and the "renaissance-age" student of Pascal, since COBOL had the notion of an ENVIRONMENT, FILES, PARAGRAPH, and WORKING-STORAGE section and Pascal required that all of its variables, functions, and procedures be placed in a unique place in the program. Plus, both languages use the concept of "constant values" whose values are set in a single location and used throughout a program. Modify a single point and affect the entire program.
The process of creating an HTML Storyboard naturally produces a partitioning of the dynamic concerns. This frees the coder from the cognitive task of identifying these concerns while simultaneously writing his web-script which is often done without much forethought or planning, a common dysfunction in the world of development. In short, a CABOOSE coder can simply be given a list of dynamic page concerns which he must populate. For each concern, he can produce a single method. This might not be the "ideal" partitioning in that some of his methods should possibly be subdivided; however, it does prevent the enormous "monolithic, big-bang" methods which perform all of the processing needed for generating all of the content for a single web page response. Plus, if one of the dynamic concerns within a page is incorrect when it is verified or validated, simply cross-checking the Storyboard template with the XML "directory" mapping file will provide the name of the method which needs correcting. Hopefully, it will be less than fifty lines of source code. This will improve debugging time when compared with locating an error in method spanning a few hundred lines.
This post is somewhat monolithic itself. Hopefully, it was not over burdensome for the "millennial-coder" of JAVA, .NET, or the LAMP Trio. Keep hunting, pecking, and thinking... The CABOOSE Team. Bing!
No comments:
Post a Comment