|
Next revision
|
Previous revision
|
emergence [2021/05/08 15:08]
9gu1h created |
emergence [2021/05/11 13:43] (current)
9gu1h [Emergent Learning] |
| ====== Emergence ====== | ====== Emergence ====== |
| CleanCode version | |
| |
| MonkeysAtKeyboards | ===== What? ===== |
| | "Emergence" is defined in terms that seem, at first, to dance around rhetorical redundancy. |
| | |
| | Aristotle (384–322 BC) is recognized as the first to describe emergence : |
| | |
| | On Aristotle’s view, human beings, like other “secondary” substances, arise from a distinctive |
| | arrangement of the four material elements. While the mental powers of human beings require and |
| | are necessitated by such an arrangement, these powers are distinct from, and downwardly causally |
| | efficacious with respect to, any non-mental powers. |
| | |
| | Let's bring this wording forward about 2300 years. Consider a system composed of elemental parts. |
| | The elemental parts are considered to be well-known in their properties and interactions. |
| | As this system increases in complexity, there can be observed additional |
| | behaviors, which are unique and distinct from the total of the properties exhibited by the elemental components. |
| | Furthermore, the newly exhibited behaviour of this complex system cannot be explained through any logical |
| | examination of the component elements and their properties. The new behaviour has "emerged" from the complex |
| | system of elemental components. |
| | |
| | Darwin used the idea of emergence to describe new behaviours of living beings that, although possibly explained |
| | by evolutionary incremental response to the being's external environment, nevertheless exhibited behaviour |
| | to adapt that could not have been predicted in any logical way from analysis of the preceeding environment |
| | and behaviours. |
| | |
| | ===== Emergent Technology ===== |
| | We technologists, especially of the software engineering kind, discuss //emergence// most often in context of |
| | SystemArchitecture (and EnterpriseArchitecture). Our systems are built of components, often independent services, |
| | which we have created to have very specific, Mathematically complete, API's. Functions of those API, their //methods//, |
| | which we call "behaviour". This system grows in complexity as we add other component-service to it, accomplishing |
| | more and greater processes. At some point, as we continue to observe the operation of this system in real-time, |
| | we begin to observe interactions of the system with client-callers that are beyond the original definition of the |
| | system nor any of it's component-services. This behaviour has //emerged// by it's complex composition, exhibiting |
| | a behaviour that previously was not predicted. Most often, this new behaviour is often surprising and could |
| | not have been predicted by any logical analysis of the component-services and their API functions. |
| | |
| | ===== Emergent Code ===== |
| | The code we write, within a single library or //application//, is a complex system of elemental components. In this context, the general limitation of the definition of "elemental" should be that of a simple function. |
| | |
| | <code typescript> |
| | def add(x, y) { return x + y; } |
| | </code> |
| | |
| | When we write "code" it is common to start with the imperative, TopDownProgramming style. Step 1, Step 2, Step 3. "Lather. Rinse. Repeat.". //Instructions// are not only concrete in the operation of our computers -- Machine Language ("Assembly"). //Instructions// are ubiquitous within our society and culture. |
| | |
| | So, we form the process of building an "idea" into code. Many steps at a time. |
| | |
| | **Many steps at a time**. This is the critical part. A complex //application//, then, has a multitude of //instructions// -- complex functions that perform many steps. Often these functions exhibit (or "perform") more than one behaviour at a time. An "elemental" function as above, then, represents a function that exhibits **exactly one behaviour**. This is the basis of the SingleResponsibilityPrinciple. |
| | |
| | Our complex application exhibits //behaviours// that are greater than the functions of which it is composed. These extended behaviours are our application's //API//. |
| | |
| | What are the elemental functions though? We started writing this application with multi-step functions, steps to describe building our "ideas" from the nothingness of an empty environment. |
| | |
| | Our complex application, as it continues to grow in complexity, also begins to cause pain to both users and developers. "Behaviours unexpected" begin to be exhibited as the user executes the application -- BUGS!!! |
| | This state of the application is definitely exhibiting behaviours that could not be predicted!! |
| | |
| | But wait... this is //CODE//! Mathematical! Cold, calculated, complete! How could we observe behaviours that cannot be predicted?? |
| | |
| | Come back to the construction of our application -- multi-step functions. With an application of "sufficiently large size", no human could be reasonably expected to be able to "memorize" the entire function set of the application. The minimum size for an "inscrutible" application is a lot smaller than anyone suspects. And this trick of complexity requires **memory**, which is often shorter than the time frame it takes to change or add functions to the system. |
| | |
| | What do we do!? **Refactoring!!** The properties required of an "elemental function" are described by Kent Beck in //Extreme Programming Explained : ch. Simple Design// ((Extreme Programming Explained: Embrace Change, Kent Beck, Addison-Wesley, 1999.)) |
| | |
| | • Runs all the tests |
| | |
| | • Contains no duplication |
| | |
| | • Expresses the intent of the programmer |
| | |
| | • Minimizes the number of classes and methods |
| | |
| | Robert C. Martin in //Clean Code : ch Emergence// associates these properties with his own traits of "Clean Code". |
| | |
| | Neither author though tells us what to expect, nor how to achieve or observe "Emergence". |
| | |
| | ===== Emergent Refactoring ===== |
| | Emergence in our //CODE// comes of Refactoring. Taking our multi-step function and first applying tests to it... to ensure all conditions (code-branches!) and exception-handling (null-check!) operate as expected... Expected Behaviour! |
| | |
| | Then we perform a step that is not obviated by //Simple Design//... divide this function into "elemental functions" -- one //behaviour// per function, one condition(branch) per function, exception-handling as an "elemental function". |
| | |
| | As we work through this process of splitting our molecular function into it's atomic components... Patterns will Emerge. Functions with similar //behaviour// can be collected together into modules or classes. Functions that act upon a single data-type can be collected together into classes. Common collections of arguments or data-blobs (Objects!) can be collected together into DataClass classes. |
| | |
| | By the continual breakdown and gathering-up of "elemental functions" -- we can begin to observe and //Emergence// of "behaviours" (data-classes, common function collections, etc) that we could not have predicted from a simple examination of the original multi-step functions. While breaking down into "elemental functions"... we continue to examine the correct execution of tests, adding tests to new "elemental functions" -- data-classes, modules, libraries. Correct execution of tests ensures no //Unexpected Behaviours// are observed -- Less BUGS!! |
| | |
| | By this Emergence of Code, and improving the stability of our application (less BUGS!!), it is now easier to "reason" about how the application operates. The code, grouped together into common //behaviours//, matches the form of concept-processing that is used in our brain. Now we can more easily understand //WHY// our complex application behaves a certain way. We also can now easily determine what changes we could make to our complex application to add or enhance it's //behaviours// (API!). |
| | |
| | |
| | ===== Emergent Learning ===== |
| | You may have detected that //execution// of the above discussions is a time-consuming endeavour! This is exactly correct; and we can lean-into this time and use it to our advantage. |
| | |
| | Our industry, specifically software technology, has become fixated on **right now**. Agile process is debunked as "too flexible" -- we want **all the design**... //now!// Testing is deferred (and forgotten!) because we want **all the results** ... //now!// This becomes especially clear in application management, when a BusinessOwner turns to micromanagement as the only tool that seems useful in attempting to control a process and effort (MONEY$$) that they do not understand. Upon examination, we want to enable that BusinessOwner to have a recurring opportunity to "guide the ship" of development, helping the development and design team respond to business opportunities and challenges as they arise. The critical theme here is that **time goes by**. Business opportunities and challenges are unkown. They come about "at a time". We cannot predict them and must take them in turn. |
| | |
| | We humans also do another important task "over time"... LEARNING. We don't learn //all the things// **immediately**. We spend //years// learning our trade, learning languages, learning about each others as acquaintances, friends, partners. We also //learn about software//. The BusinessOwner learns about how the software we're building interoperates with the business process. We developers learn how the software is used (in unpredictable ways!!). We encourage the BusinessOwner take //time to learn//, leaving space in the planning and design process to **learn as we go**. |
| | |
| | Similarily, in refactoring our code, we need to give //time to learn//. Small refactorings don't necessarily take days to contemplate and review. We //do// need to give ourselves time to reflect on these small refactorings and //learn// the larger themes and modules that are. ... wait for it... **EMERGING** from the previous work. |
| | |
| | Emergence comes from learning. They are a form of each other. Emergence begets learning. Learning begets Emergence. |
| |
| Embrace | |
