A rant about Front End Developers not knowing Modular Programming

I find myself these days needing to teach many Front End Developers about basic software engineering principles that they didn't even know they didn't know. Here is a rant based on a post of mine to an internal support forum at a client site. I keep finding FEDs that think that any piece of DOM, bit of JavaScript, or chunk of CSS that they can see via Firebug is fair game to fiddle with, and they ask in all innocence why that is a bad thing! ...rant...rant...


Why does my App break when I upgrade to the new version of the Framework?

This thread is a general purpose Q&A on the topic of code breaking when a newer version of [GUI Framework] is used, and it is illustrated by a particular real-world scenario...

Example Question: "The following code was provided to us by [GUI Framework] team for auto complete in [widget] a long time ago when we were working on the [foo project] with the [GUI Framework] team.  In there, you can see there are quite a few references to the private attributes. ... ... ... functionality is not working as before. Can you please provide pointers to resolve this."

Example Answer: "... A quick look at the code in the attachment makes me believe that it was a hack to replace the internal workings of the list filtering…you SHOULD have been provided an above-board way to subclass/decorate/configure [widget] (instead of that quick and dirty method)."

There are general software engineering principles of "encapsulation" and "information hiding" which come from the Modular Programming era in the mid-1970s (just before Object Oriented expanded upon it).  To combat "brittleness" of a system, Components hide their (private) implementation details inside a (public) interface so that changes in one part of a system don't break other far-flung parts of that system (aka "loose coupling").  The warranty provided by the component is that as long as you use it as designed, and via the stable interface, the insides are free to be changed/fixed/enhanced without affecting you.

So, a component (where "widget" is just another word for component) is not just a collection of functionality like the collection of bits and wires below...

 ...but rather a collection of functionality that has had a stable interface published on the outside of a "black box" thus hiding the implementation inside that box, as shown below...

This warranty is voided however if you break into the box and connect to its private implementation (aka "hacking") as seen below...

 In [GUI Framework], there are two major indicators as to whether a property or method of a widget is public interface versus private implementation:

1. If the name of the property or method starts with an underscore ("_") then it is definitely private (or at best "protected")
2. If the property or method is documented in the [GUI Framework] JsDoc API Docs then it is definitely public.

SO, IN CONCLUSION, if someone advises that non-documented or private parts of a widget be used by your app, you should get them to sign a document acknowledging that they are voiding their warranty, and they will pay the costs incurred when components are replaced or upgraded later (as they will be EVEN IF YOU REMAIN USING THE SAME VERSION OF [GUI Framework] because only the Interfaces are promised to be kept stable for a release, not the Implementations!)