|
| A Brief List of Reasons for the Claimed Huge Productivity Gains |
|
| The objective of this paper is to prove that large savings is most certainly possible for large applications and in real life scenarios or practical conditions. Many people asked me, if I can demonstrate large savings (that I claim for large software systems), if they assign 2 or 3 junior engineers for 3 days. That is, can they do the same application that normally takes four days in three days? |
|
| The components and CBD can have very little use in case of such small applications and especially in such simple academic settings. The reasons are listed below, which are not exhaustive but more than sufficient to conclusively prove that the RSCCs and CBD-structure offer huge benefits for large software applications, where the software application is useful (or being used) and must be evolved or maintained for few years. |
|
| 1 |
In an academic setting, the programmers implement the application perfectly the first time (since no one ever uses it, once it barely satisfies simple pre-defined test criteria – It is just aiming a simple fixed target). |
| |
| 2 |
But in practice, software development is a moving target. The developers don’t know what customers want. The customers don’t know what they really need even now (and it is nearly impossible to predict even the near future needs). The needs constantly change or evolve. |
| |
| 3 |
There are many more miscellaneous factors such as, the technology landscape is evolving. The business rules, policies or government regulations change constantly. The competitive landscape is constantly evolving, due to innovations and improvements. |
| |
| 4 |
Each developer gains valuable insights and expertise during the development of each version and from the user feedbacks soon after releasing each version. It is desirable to leverage this at each stage for each component quickly and painlessly (e.g. while all these still fresh in his mind, before he forgets or leaves. See sandboxing and versioning below). |
| |
| 5 |
The software projects are much bigger. The project teams are much bigger. The initial design and development takes many months to more than a year. |
| |
| 6 |
Any useful system requires maintaining and building newer versions periodically for many years to even for few decades. |
|
|
FIG-1:
Code/Device-Structure of an application having 3-SCC |
FIG-2:
Structure of an application built by assembling 3-RSCCs |
|
|
|
Today the life of the application having three large custom SCC
begins as spaghetti code as shown in FIG-1. It is certainly
desirable to: |
| 1 |
Sandbox the code base of each RSCC: A set of files must comprise substantial portion of the application code implemented exclusively
for each RCC (of a SCC), so that no other code for any other SCC or application need to be changed or even touched to frequently refine the SCC little-by-little.
|
| 2 |
Versioning the code base of each RSCC:
Since a set of files comprise the source code of a SCC, it
is possible redesign, test and create versions of each RCC
independently from the versioning of the container
application (See FIG-3 below). |
|
|
|
| 7 |
Senior developers move to greener projects and replaced by new often less experienced developers (need to grasp existing complex code base FIG-1). |
| |
| 8 |
The developers usually revisit a large component after long gaps (e.g. few months to a year), by then the landscape surrounding the code-sections for the component likely have changed substantially (see FIG-1). |
| |
| 9 |
After a long gap, the design and code is no longer fresh in his mind, so takes lot of time to even locate appropriate code-parts (and decipher complex interdependences of each code-part) of a SCC for redesigning to create a new version of the SCC. The software-parts, code-sections or sub-modules (shown as devices in FIG-1) of a SCC are usually tightly coupled, while the RSCC in FIG-2 can be designed to be loosely-coupled. |
| |
| 10 |
In the above step or process the developer of SCC changes the landscape of code-section (e.g. software-parts or devices) of other SCCs developed by other programmers. He also likely alters the interfaces of the devices (i.e. software-parts) of other SCCs, if the other SCCs collaborate with the SCC. |
|
|
FIG-3:
Versioning of code base of a sample RCC/RSCC |
| 1 |
It is possible to create multiple sub-versions (e.g. V1.R3/R2) as shown in the small dotted boxes for experimentation or to offer selection (or choice). |
| 2 |
The code base of any version (e.g. V3 above) of 1st application can be used as a base to custom design a version (e.g. V1 below) for 2nd application, where each application end-up having separate code-base (therefore, it is only reuse of code-base and not reuse of the component). |
| 3 |
It would be much simpler to cross-pollinate ideas and innovations between components (e.g. V3.R3 and V5) belong to two multiple applications. |
|
|
|
| 11 |
Our invention allows Independent evolution and versioning of each of the large components in the CBD-structure of an application (See FIG-3). |
| |
| 12 |
Today only product level versioning is possible. It is not practical to selectively restore an old version of a SCC. Multiple file contain code base for multiple SCCs (See FIG-1), so restoring an older version of one or more files resulting in loosing the changes made in these files for other SCCs. |
| |
| 13 |
Inability to versioning strongly discourages experimentation and choices. They are not only extremely valuable but also often essential for innovations (e.g. to rapidly react or evolve many times faster than competition). |
| |
| 14 |
The code base of each component is sandboxed, so a new developer of a bad programmer can’t cause any damage to other parts of the application. (A) The sandboxing of code base of each component keeps programmer of the component within the sanbox and (B) the sandbox also keeps the programmers of other parts of the application outside, hence prevents them form touching or altering the code base of the component. |
| |
| 15 |
Today it is not possible to sand-box each large component (i.e. SCC). Hence, if a new engineer deforms, defaces or spoils code sections of a component (i.e. SCC), it is not practical to restore the old version. |
| |
| 16 |
The ability to versioning each RSCC allows easy and frequent Refactoring code base and testing of each version of the RSCC/RCC individually. |
| |
| 17 |
Today it is not practical to extract and re-use code-base of a component-version for creating a custom component for another application. |
| |
| 18 |
The ability to versioning each component, substantially increases the reuse of knowledge and source code. |
| |
| 19 |
In practice, each large software company (e.g. Infosys, TCS or Wipro) has over 100,000 software developers working 50 weeks a year in large groups for maintaining each of multiple large software systems. |
| |
| 20 |
The cumulative effect of all these factors can’t be demonstrated in a small academic experiment by developing three small components in just 3 to 5 days by three developers. |
| |
| 21 |
However, we can demonstrate hundreds of CBD-structures, where each CBD-structure is built by assembling real components. This proves that most of the large software systems can be built as CBD-structures by assembling real components. |
| |
| 22 |
There are many other factors that influence the complexity and factors that can be leveraged to overcome the complexity and to increase the productivity, for example: |
| |
| 23 |
History has irrefutable proof that, the biggest contributors to the productivity gain are not the widely known simple to grasp factors such as reuse or standardization but less know hard to grasp factors such as increasing the degree of (i) division-of-labor, (ii) specialization or (iii) automation. |
| |
| 24 |
We can prove the fact that widely known simple to grasp factors such as reuse or standardization of components are very useful for mass production of product models belonging to mature or crowded product families such as cars or cell-phones respectively. |
| |
| 25 |
These factors such as reuse or standardization of components can play very limited role in case of designing and developing prototype of one-of-a-kind products such as spacecrafts or experimental jet-fighters. The design and development of software is more like developing prototype of such one-of-a-kind products, since software industry introduces new products belong to thousands of product families. Imagine design and engineering process of a new innovative product (e.g. Building first Airplane by Wright Brothers). |
| |
| 26 |
We must recognize and accept the fact that we must implement hundreds of thousands to millions of lines of custom code for each of the large software applications, even after leveraging all the best infrastructure, tools, methods and using all the available reusable software parts and libraries. |
| |
| 27 |
However it is possible to organize millions of lines of custom code into CBD-structure (by discovering innate nature of real components), by leveraging the fact that neither complexity nor one-of-a-kind uniqueness of the physical products can prevent designers from achieving the CBD-structure. |
|
|
| If a reviewer temporarily assumes that it is simple to design any large software application as a CBD-structure, then would he agree that such design offers huge productivity gains as claimed? Are the above points valid for each of the real components in the CBD-structure? |
|
| If answer is Yes, then all we need to prove is that (i) any large application comprises multiple SCCs, where each SCC can be implemented as a RSCC, and (ii) the structure of the application end up as a CBD-structure, if all the large SCCs in the large application are identified and designed as RSCCs. One must grasp hidden nature of the real components to identify the SCCs. Even if a small portion of the large SCCs in a very complex and large application are designed as RSCCs, the ability to versioning and independently evolve each of the RSCCs offer considerable productivity gains over the long life span of the application. |
|
| Essential purpose of the real component-based engineering is ability to look, feel and test each component to optimize individually for making each component as best as it can be. Then bring the components together periodically to make sure that (a) each of them properly collaborating with other parts, and (b) all the components are fulfilling their respective roles as intended. Pay attention to 15-Secs starting at 1.55min http://www.youtube.com/watch?v=hc5e5cYdshI. |
|
|
