Wednesday, March 19, 2014

The essential nature or purpose of ideal components is superior plug-in/unplug modularity

          Today software engineers could leverage huge infrastructure comprising tools, compilers, RDBMS and reusable libraries for building software applications. Even after using all kinds of available libraries and tools from the mature infrastructure, today many large applications still require implementing millions of lines of custom application code. It is impossible to avoid implementing custom application code, so it is designable to modularize the custom application code into replaceable components (which can be unplugged by deleting 3 to 5 lines of code and plugged-in by implementing 3 to 5 lines of code), which must achieve highest possible modularization by eliminating all the reasons that cause spaghetti code (e.g. to effectively disassemble, re-assemble after redesigning or to replace):   

My Research Goal is to invent a new kind of software components that can achieve a new kind of CBSD (Component-Based Design for Software Products). The characteristics of the replaceable components are (i) no component must require more than 3 to 5 lines of code to plug-in the component as a unit, (ii) must encapsulate few hundred lines to few thousand lines of application code and (iii) removing the said 3 to 5 lines of code must effectively remove the component as a unit (leaving no traces of any associated application code). These new kind of components are referred to ‘replaceable components”, since any component can be removed by removing 3 to 5 lines and replaced by another equivalent component by implementing 3 to 5 lines of code.

            If an application needs implementing 200K lines of application specific code and if I am responsible to implement 20K lines of code. Why should I be forced see even single line of other code implemented for the application (where the other code was not implemented by me). Excerpt the code I am responsible for implementing, I wish, I must not be forced to see even a single line of code by other developers against my will or choice.

            Likewise, excerpt the code he is responsible for implementing, no other developer writing code for the application must be forced to see my code or code implemented by any other developers against his will or choice. Each developer should be able to design, develop and test his components to make each of his components as best as it can be (before plug-in each of his components in the application for further testing). He should be able to use SCCS (Source Code Control System) to version each of his components.

            To implement my 20K lines, I need to start implementing one line at at time. I must be allowed to focus on just my code, without any interference or noise such as forcing me to see other code implemented for the application, which is the application code not implemented by me on which I have no control or want any control.

This must be true for all the developers, whenever any developer need to redesign his/her components any time in the future throughout the evolutionary life-cycles of the component and the product that is using the custom component. Each developer should be able to checkout the source code for any component from the SCCS and redesign it for creating an improved version or to offer more than one version to offer a choice.

Although we in software may think this kind of components are revolutionary, illusions or fantasies, the designers of complex one-of-a-kind physical products (e.g. prototype of a spacecraft or experimental Jet-fighters) take this kind of components for granted and don’t even notice to appreciate what they have (which are consider science fiction by many scientists of computer science or researchers of software researchers).

Today me or any other developers is forced to add his code-sections (often implemented one line at a time) to multiple non-exclusive application files, where more than one developers are forced to add his code-sections (often implemented one line at a time) to the non-exclusive application files. This creates unnecessary interference and complexity leading to spaghetti code, since each developers often need to revisit the code-sections in non-exclusive files to fix or to optimize the features as he gains more and more insights into the application design and user needs (as he has been coding one line at a time to implement more and more code and thinking each and every day).

The structure of the spaghetti code implemented in non-exclusive files progressively degrades as each of the components is redesigned for future releases in the normal evolutionary life-cycles of each of the components and the product comprising all the components.

The reality is, many developers would leave the product development and new developers join to replace the product development. The writing style and thinking of any two English writers hardly matches: How can we expect two junior developers would think alike (especially under the stresses of release datelines and girlfriend problems)?

For example, I created few components for an application for KLA-Tencor in 1994 and I was proud of my design (maximized exclusive files). I took a long vacation, nearly 4 months and another developer was asked to add few features to my code for an intermediate release. After returning, my boss told me that the other developer complained that my code and style was very hard to understand. I implemented 2 to 3 entry points and 3 to 4 exit points (I don’t remember correct number). To add few features, he changed the structure of the code, which I had hard time understanding, when I took back control over the code. He changed the structure and unnecessarily added interfaces to entry and exit points (instead of changing the existing interfaces).

I am sure, any designer could identify many SCM (Self-Contained Modules) in any large software application, once the essential characteristics of ideal physical functional components are discovered, and where the essential characteristics are characteristics uniquely and universally shared by each and every known large physical functional component exist today.

Any harm could fell upon computer science, if scientists and researchers of computer science discover facts (i.e. the essential characteristics). I never heard of any truth that harmed any field of science. My understanding of ideal functional components is modularization. No other kind of physical part can match the modularity of physical components. All I am requesting research community to discover the hidden nature or characteristics that are allowing the physical components to achieve such superior plug-in/unplug modularity.

It is not necessary that even a single component in the hierarchy of replaceable components (i.e. CBD-structure) posses any of the characteristics (e.g. reuse or standardization) erroneously attributed to so called software components known today. Inventing more kinds of reusable modules to minimize the required application code is a noble goal. But my goal is not in conflict with such goals, as clearly stated in the first paragraph. For example, each component for City_GIS is custom designed to satisfy just one target application.

Other software component researchers were working on increasing the degree of modularity. To them, I request to remember, no other kind of (either software or physical) module could match the modularity of the physical components. Only difference is, the designers of physical products have them and we still need to invent them (by discovering the essential characteristics).

Nothing strengthens a truth or once faith, more than then being rigorously tested. Many experts convinced that I was wrong or even crazy to say: It is an error to blindly define/dictate nature or essential characteristics without any basis and reality. Fortunately I created hundreds of real-components and component hierarchies between late 1998 and 2003 (I only worked part-time). I could fall back on them and create few more to reassure myself that I am not crazy. Irresistible curiosity forced me to focus full-time on this research since 2003.

My faith in this discovery has been well tested and I am more confident than ever. If I am wrong, no one could be bigger looser than me, because I invested more than 12 years of my most productive life and spent lot of money on securing US patents on essential characteristics of real components, enabling tools such as GUI-API and intelligent CASE-tools.

The biggest fear to me is not loosing the time and money, but some one else finding a real error (that I might have missed), which can prove to me that I am really crazy (death probable better than such humiliation), because I disputed and disagreed foolishly with respected experts of our field. I had many nightmares about such possibility and woke me up in the middle of night. I had to spend few days to re-assure myself. That is the reason, I am only asking the researchers to just discover the truth, if they agree with scientific process: Relying on erroneous facts (by not knowing the truth) to advance technology could cause irreparable damage to the technological progress:

All I am requesting is, please invest few weeks of your valuable time to discover the essential characteristics. Based on my decade of passionate research, I believe it will be well worth the investment or risk (even if some researchers feel it is a risk).

Best Regards,

Raju Chiluvuri

No comments:

Post a Comment