| |
Brief Background and Summary for Sandboxing & Versioning
|
|
Engineering historian Dr. Henry Petroski illustrated in his famous 1992 book
"The Evolution of Useful
Things" that:
| 1 |
Continual refinement is the usual rule and |
| 2 |
Engineers constantly find shortcomings in their designs and fix/refine them
little-by-little |
|
|
It is highly desirable to fix/refine each of the large components little-by-little (in the step-1 or step-3 of
CBD-process) for evolving multiple component of a complex CBD-product. |
|
|
|
Each physical product (e.g. cars, airplanes or computers) is evolved by improving each of its components
little-by-little individually (by designers or vendors of respective components). For example, designer of the car-engine refines the engine
little-by-little autonomously away from the car. Likewise,
vendors of CPU, Hard-drive or Jet-engine refine respective components little by little
individually away from respective products computers or airplanes.
|
|
|
It is not practical today in software to refine and test each of the equivalent larger Self-contained components (having many sub-components) individually outside of its product. For example, this ability to refine each component independently outside of the product and also test independently outside of the product, must had helped Wright brothers immensely not only in building the 1st functional Airplane that had taken 1st successfully flight but also to improve the airplane few more iterations or models.
|
|
|
Even today mankind is inventing many new products. For example, see a brief video about inventing artificial-kidney and kindly pay attention to 15-Secs video starting at 1.55min
http://www.youtube.com/watch?v=hc5e5cYdshI.
|
|
|
Essential purpose of the real component-based design 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.
|
|
|
Sandboxing of the code-base of a SCC using a RCC:
|
|
|
FIG-2 shows an application comprising three SCCs, where the construction code for each SCC is encapsulated in a RCC. Then each SCC is assembled into the application using respective RCC, where the construction code for each SCC comprises multiple parts, which are represented by a shape. For example, the parts of first SCC are shown as cubes, and parts of second-SCC are shown as pyramids. The shapes have no other purpose except to visually identify parts of construction code for each SCC. If parts of construction code for each SCC is not encapsulated in a RCC, the parts likely be spread across the application almost randomly as shown in the
FIG-1. The shapes are used only for illustrative purpose, so the code-sections created for each SCC might not be so easily distinguishable in the application of
FIG-1.
|
|
 |
 |
|
FIG-1:
A Simple application comprising 3-SCCs, where a shape is used to visually
show parts of each of the SCCs (e.g. the parts of a SCC is shown by using
qubes and parts of another SCC is shown by using pyramids. |
FIG-2:
The same application can be created by using 3-RCC, where each RCC is
designed to encapsulate construction code of a SCC and assemble the SCC in
the application. |
|
|
|
The purpose of any RCC and all the associated code-base are to encapsulate all the parts of construction code of a SCC and associated resources in a set of exclusive files (where the set of exclusive files must not contain parts of any other SCC or rest of the application). In this case, if any developer needs to redesign or add features to this SCC in the future, it is not necessary for him to touch or even see code for any other SCC or part of the application (i.e. he is boxed-in). Likewise, it is not necessary for any developer to touch or even see the code for the SCC, when he is redesigning or making changes to any other SCC or part of the application (i.e. he is boxed-out). This website refers this kind separation of code-base of any SCC as
sandboxing.
|
|
|
Versioning of the code-base of a SCC using a RCC:
|
|
|
As explained above, a set of exclusive files are implemented to comprise all the parts of construction code and resources exclusively associated with a SCC for assembling it as Replaceable-SCC (or RSCC) into an application. FIG-3 illustrates versioning of a code-base of a RSCC. For example, the code base of RSCC for CityTheaters (in
City_GIS application) can be implemented as an independent application in a set of files and the set of files can be versioned, for example to improve
little-by-litter or for experimentation (or to make it as best as it can be).
|
|
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. |
|
|
|
|
The versioning can be used for tracking all the exclusive files of each version of a RSCC by using a tool such as SCCS (Source Code Control System), RCS (Revision Control System) or CVS (Concurrent Versions System). A version control system can keep track of changes to the code-base by using a version number. The code-base of existing version is used as starting point for creating next or subsequent version of the RSCC. Also the code-base of a version is used for creating multiple revisions, for example for experimentation or to have more than one variation to choose from.
|
|
|
The code-base of version-3 (i.e. V3 of an application) can be used for creating a new version (i.e. V1 for another application) of custom RCC for another application (see FIG-2), if other application requires similar RSCC. Now each of the RSCCs of these two separate applications can evolve individually, but possible to copy innovations from each other. Of course, it is possible to cross pollinate ideas and innovations between the two RSCCs evolving separately. In most case, we discourage re-use of RCCs (e.g. it is most likely the needs and release schedules of each application would diverge).
|
|
|
The software products are uniquely different from physical products. For example, if a person purchases a Camry, he won’t ask Toyota
company that the car must be evolved into a Lexus within few years by refining each of the components
little-by-little (every few months). But the customers (e.g. JP Morgan, AIG, Exxon or
Wal-Mart) of software outsourcing vendors (e.g. IBM, Infosys or Wipro) expect
the first release version of a complex software product must be frequently refined little-by-little
(every few months) and must be evolved substantially overtime.
|
|
| 
|
|
|
Although a large application may have hundreds of RCCS, the above figure shows evolutionary paths of 9 RCCs in an application. The code base for each RCC is
sandboxed and can be independently versioned. In the figure, each node in the path of each RCC is an intermediate test-point, for example, to show to stakeholder for getting feedback or to test updated coupling interfaces. The developer of each RCC can continuously refine his component ‘little-by-little’, which can be a continuous uninterrupted process, and only pauses for each major release of the application, where the pausing period for each release is shown in
the shaded boxes. The green nodes indicate the final version used for the
release, which is also the starting point for resuming the 'little-by-little'
improvements for intermediate patches and for next release.
|
|
| 1 |
The benefits of sanboxing include: allow refining each component little-by-little individually to make it
as best as it can be. |
| 2 |
The benefits of versioning include: allow creating multiple versions for experimentation or provide options to choose
(or evolving each RCC independently from container product). |
|
|
Real-CBD eliminates useless Interferences & cognitive dissonance
|
|
|
Please kindly understand the fundamental difference between two processes (i.e. illustrated by FIG-1 and FIG-2) for implementing a simple application having three large components (i.e. SCCs). If three engineers are working on the three components (i.e. each component is implemented by an engineer) and takes 6 weeks for each engineer to implement a component assigned to him. This implies, each engineer implements few lines of code or parts of the component each day. He needs to frequently test or debug (e.g. by using debugger of IDE-tool by stepping through each line of) each part to make sure it is working as intended.
|
|
|
If the code base and parts of each component is implemented as in FIG-1, interference and cognitive-dissonance between the three engineers increases as they implement more and more code (since most of the files created for the
software product comprise source code for more than one SCC). It is an obvious
fact that, this kind useless
(or accidental/non-essential) waste and complexity is already eliminated for the
physical CBD-products by implementing each physical-SCC as a replaceable-component
(as in FIG-2).
|
|
|
Of course, each engineer can’t implement perfect SCC first time, so he need to refine
little-by-little for making the component as best as it can
be, by leveraging the expertise and wisdom gained while implementing the SCC and from customer feedbacks (e.g. if customer evaluates functionality of the SCC). It is extremely desirable
to minimize the complexity for frequent changes to the source code of each SCC, which can be accomplished much more effectively and efficiently if each SCC is designed as a RCC.
|
|
|
In reality, many applications are much larger comprising hundreds of large SCCs and require several months for implementation. Each engineer implements multiple SCCs and need to revisit certain SCCs after gaps of few months. He can be easily lost in the code to find all the parts of any SCC, if the SCC is implemented as in FIG-1, and the landscape for the code base could be changed by other developers for changing other SCCs.
|
|
|
The Real-CBD increases productivity by eliminates useless interferences and cognitive dissonance, and allow the developers to solve essential complexity. In his seminal paper “No Silver Bullet: Essence and Accidents of Software Engineering “, Dr. Frederick Brooks referred this ‘interferences and cognitive dissonance’ accidental complexity, which can’t be eliminated.
|
|
| |
