Monolithic Methods and CABOOSE

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!

CABOOSE Philosophy Review

We promised at the beginning of this weblog that we would follow the KIS (Keep It Simple) principle. At times, it might seem that we have deviated from this. This entry is an attempt at simplifying the CABOOSE approach for those who are somewhat befuddled by the software engineering jargon and concepts.



A CABOOSE system with a model-view-controller architecture has five basic parts:

• The view, or rendered markup page which one will see in a web browser or viewing container.
• The page concerns, stencil tags, replacement variable, or placeholders in a user-defined form such as: #IDENTIFIER_FOR_REPLACEABLE_TEXT#. They are dynamically replaced with content from bundled methods based upon an XML-based configuration file. 
• The prepackaged controller kernel in the form of a servlet or JAX-RS web service. This regulates the flow of information between the model and the view based upon this same XML-based configuration file. 
• The model which contains the markup content with the substitute-able stencil tags which a browser might render, other external data sources, and the bundle of rendering methods which replace the placeholders in each page of markup with the appropriate content.
• The XML-based configuration file which maps between requested views and stencils plus page concerns and content rendering methods.

 

Hopefully, this will clear up some of the confusion. CABOOSE is an example of code reuse, in that, the controller is pre-written. Also, this greatly simplifies code development since that rendering method bundle is composed of simpler routines which return a formatted string. In the realm on JEE, many of the non-core JAVA concepts are abstracted out of the rendering methods. So, if you can write "Hello World" - style JAVA methods, you can use CABOOSE for web application development after a short and easy learning curve.

We apologize for letting the weblog sit idle for a few weeks. We have been working on a couple of papers again. The source for this project is available as a NetBeans archive in an earlier post. So, review and modify it as seems appropriate.

Happy Coding...Hunt...Peck...Think...La..La!!!

The CABOOSE Team