Brief: This is a Meta-methodology for reflection and improvement, with software development as its concrete domain, but being a meta-methodology, it should generalize across domains. It takes any one subject project, and generalizes its methodology to other types of domains regarding the TRM-practitioner him or herself, but not to other instances of the same domain as the subject project. TRM draws content from vastly different domains, such as psychology, physiology, and lifestyle, into the TRM sprint review, which is the core of the engine of reflection and improvement, then with regard to the target product but also the practitioner/developer him- or herself.
Concrete: Concrete content is provided, in the form of file templates and description of methods etc.
Abstract: It is hyper-structure in the sense it takes the structure of TRM that is focusing directly on organizing methodology around a given project, and gives the meta-structure of transference, allowing the TRM methodology to simultaneously reach vastly different domains beyond the initial TRM subject project, reaching domains such as those of the TRM-practitioners very own being---such as the psychological, physiological and lifestyle etc, of the practitioner. The TRM method is a self-reflective and self-improving method, which means that it is not just a method for structuring the development effort, but also a method for structuring the practitioner's own self-development. This is the essence of TRM, and it is what makes it a meta-methodology. In TRM, any single project is a viechle for the greatest project of the practitioner him or herself.
Structure of the document: This follows the ontology of SoCM, which is an ontological model for exhaustive perceptual clarity. Therefore, this document is not a "README" in the traditional sense, but rather a conceptual framework for understanding the TRM-practitioner (TRM) method.
Identity describes...
Solo development in spare time is a highly volatile environment as anything can and will interrupt the work. It requires a high level of goal-oriented dicipline, as there are countless distractions awaiting your attention, and no supervisor to hold you accountable. For this reason, only the elite among computer hackers stand a chance in aspiring to earn the title and reputation of being a real TRM-practitioner.
While TRM aims to facilitate the development and delivery of a quality product, its practice instills its principles in the practitioner, such that it comes to encourage a more sharp, goal-oriented and disciplined approach to also other things in life, thus shifting the axis of the practitioners lifestyle, which are the core values and perspectives, towards a more productive and effective way of living. In other words, and as necessary to exprecss precicely, it brings the practitioner to greater fitness within the environment. A true TRM-practitioner realizes that, while he is working on the product of his choice, ultimately, he is also working on himself. The product is a means to an end, and the end is the development of the practitioner. The product is a tool for self-improvement, and the method is a way to structure that self-improvement.
Within the TRM method's imedeate subject area, in contrast to its more general subject area of the practitioners self-development---as described above---TRM is a method to achieve production value within the easily overlooked but very real constraints of a solo project developed in spare time. TRM aims to facilitate the dilivery of a quality product, by quality means. In order to secure methodological and preformative excellence, TRM identifies two overarching aspects that must be carefully attended to:
- The TRM method itself must be continiously developed and attuned to support the development of the product.
- The second aspect is the actual product effort---the very development activity that is structured by this solo-TRM method.
Thus, we have on the one hand effort, and, on the other, a method for how to structure that effort. Both must be subjected to reflection and improvement. It is not enough to develop the product, the method and the execution of the effort must also be developed. This self-reflective approach is the core of TRM.
-
The project is developed in spare time, which means that the time available for development is volatile. Because I do this project in spare time, anything can interrupt the work, and I do not have the benefit of a fixed schedule and protected time for the project. Therefore, and the methodology must be fast to pick up where it was left off, and be able to gracefully handle interruptions. For this reason, working-sessions are calculated by the minute, and not by set of hours divided into blocks of days.
-
The project usually has an indefinite time horizon. No deadline exists, because it is a spare time project. Any imposed timeline is arbitrary and can easily be changed by the developer.
-
Similarly to the project's time frame being arbitrary, the project's quality is also arbitrary. The developer can settle at any level because the final product is measured against the developer's own standards, which by the way may change troughout the project for better or worse. It is well known among spare-time developers that a project may start with great enthusiasm and high standards, only to devolve as tedious tasks remove the initial motivation, only for the developer to finally make compromises just to get done with the project and move on.
-
With a spontaneous engagement, driven by internal joy rather than demand from an external authority, the development process is prone to shift drastically in focus, direction, and engagement.
-
While a creative and explorative process has great value, a spare time solo developer may get lost in faschinating details and lose sight of the overall goal.
-
A spare time solo developer may have to resume the project after a day of ordinary work, and may experience fatigue, which can lead to a lack of focus and productivity.
-
The aspect of working alone means there are no other team members to help guard against bad decissions and no one to help finding the better solution. The spare time solo developer is more prone to make bad decisions, compared to the ideal case of a set of skilled team members working together.
-
The lack of external expactations, such as from a team, and the lack of social reward from doing the right thing, means that the spare time solo developer has less such incentives to do the right thing, and if those motivating factors are core to the developer's sense of meaning, then the developer may lose motivation to continue the project after the initial engagement. Also, if the expected reception of the product is not high, the developer may lose motivation to continue to adjust and refine the product and instead give up on it. In such case, a team of developers would be more prone to make a fair assessment of the projects possible success and the path to it.
-
The aspect of the TRM methodology that is dealing with the subject project, must be able to be transfered to other domains, such as the developer's psychology, physiology, environment etc., which, when improved, directly also improves the efforts and abilities within the project-specific TRM-methodology, and the method must be able to reflect on itself and improve itself.
-
Should have an aspect of minimalism in the documents produced by using TRM, as product, rather than documentation, is the main focus of the TRM method.
TRM constitutes of:
- A method for how to structure the development effort.
- A set of principles that guide the development effort.
- Feedback-loops in the form of reviews and retrospectives (reflection on the process).
- Documentation incorporating the principles
- Documents for feedback-loops, checklists, evaluation and more.
- An underlying general cabability of transferability, with the assertion that a deeper essence, a truth independent of time and space, can be progressively realized and embodied buy practicing the self-reflective method of TRM. This essence is not easily understood, but absolutely potent in progressively leading to spiritual harmony as progressively realized. If TRM does not consist of this assertion of transferability, then it is not TRM, but merely a method for structuring the development effort. The esoteric dimension is that which is reached when the self-reflective and self-improving method of TRM is applied. When the TRM method is applied to a project, there is a knowing of what is good and bad---otherwise one thing would not be selected over another, and this method enforces selection and requires a knowing of what is preferred and what is not. The TRM exercises awareness and discernment, and the claim is that this practice of TRM elicits the propensity for awareness and discernment of more general patterns in life's all dimensions---socially, psychologically, habitually, physiologically, spiritually, etc... The self-reflective and self-improving aspect of TRM, which elicits awareness and discernment of everything, is the method by which the developer progressively can come to understand non-obvious realities and thus adapt the method even better (such as the implications of a complex web of the own habits, attitudes and beliefs). TRM transcends the scope of its subject project, in the sense it encourages self-reflection and self-improvement also of also other things, like the health of the practitioner, the allocation and use of time, etc, and the result of such self-reflection and self-improvement returns benefit back to the development of the project. TRM encourages its own application in other areas, because in the quest to improve the product, the developer will be open to question and reflect on everything that seem related, thus moving the area of reflection to non-obvious things. The practice of TRM in dealing with the subject project, will improve the developer in this way of encouraging wider self-reflection and self-improvement, and the developer then improves the method and efforts of the project based in the newly gained self-improvement, and thus the project itself. The transferability of TRM to other domains is that very reality which enables the TRM methodology bridge over to another vastly different thing and enables self-reflection and self-improvement on also that. This transferability hints at something much more general, which is able to transfer the same methodology to a vastly different thing. The understanding of, or the knowing of this thing of transferability, is a meta-method to TRM in the way that this mechanism enables reflection and improvement of anything. Thus, TRM can reflect and improve its subject project, but simultaneously, due to this meta-method, reflect and improve anything in any domain, to aid the project,... and importantly; improving those seemingly unrelated domains does not just help improve the subject project, but also improves other things. Thus, it is a network of improvement, not a linnear model. Improvement is defined as purposeful and healthy adaption. Addaption is an indication of awareness, and also; purposeful adaption is the evidence of discernment. To understand TRM esoterically is not to understand more facts, but to become more structured, aware, and discerning. It is the becoming that is the point, and it is in the doing that there is knowing.
- Rituals.
- Here, specifically, adapted TRM rituals, like cycle criticism.
- The very first improvement that TRM necessitates is the root-commitment. This is the initial commitment that is the root of all improvements possible. This is the commitment to the TRM method itself. Commiting to it is necessary for the method to work. The commitment is a one way path, meaning there is no turning back. The commitment is taken by trying out, and reaching a place of heart where the commitment is made with confidence and absolute certainity. Then there is no turning back, but the wheel of improvement has been set in motion, and will continue till any possible highest state has been reached. The commitment does not necessiate belief, but requires adherance to the TRM ritual such as the adapted TRM sprint-review. The has been fulfilled when the heart knows it has, and it has been failed equally by the heart knowing it has failed. Without the power of the root-commitment, the TRM will not gain its real power. The root-commitment is such that if the method doesn't work, then the practitioner will not give up, but will instead reflect on why it didn't work, and then improve what needs to be improved. The root-commitment implies effort in reflection and improvement without restraint and hesitation.
TRM ocnsists of two subjects: the developer and the product:
- A solo developer.
- Spare time.
- Relevant skills and resources.
- The specific development efforts.
- A vision of a product to be developed.
- An environment in which the product is to be developed.
- An environment in which the product is to be used.
- The health of the developer, which is a prerequisite for the development effort to be successful.
The developer and the product are seen as integral to the TRM method itself. They are not seen as separate enteties on which the TRM method is applied. This is because the developer's and the product's continiously evolving state comes to inform and reshape the TRM itself during the process. TRM thus is not a static description of something to be applied, as you may think when reading this text, but is a description of a reality that is embodied by the developer, and merely is being described here. The developer can not read this and apply it to something without also himself or herself being the subject of the method. TRM thus is not a prescription, but a description of a reality that is being lived by the developer. The developer is the method, and the method is the developer. The developer must become the method he or she uses.
TRM thus is constituted also by a meta structure in the sense of being self-reflective and self-improving. At the ordinary level, TRM gives a structure for how to organize goals and review them, and at the level of the meta-structure, TRM reflects on tits ways of organizing things and the way it directs action. The meta-level exists for the sake of maximizing fitness in reaching the product goal. TRM goes so far as to seek to maximize the developers fitness even with regard to health, for the sake of aiding the aquisition of the goal. TRM places demands on the developer, and the developer, just like the product, progressively takes shape in accordance with the vision of the project.
The requirement of minimalism, and ...
This is adapted for rapid development, thus no time frames are set, but work is done with the aim of doing it as quickly as possible. There is no point in setting a time frame, as "as fast as possible" is the overarching goal. However, this must not imply a careless work, but the process must strive for a flawless execution and excellent result. Thus, the process should not be at the cost of the health or long term status of the developer, but should rather make the developer more sharp, intelligent and capable (for this, the self-critical step of "Cycle Criticism" is central). Likewise, the quality of the product should not be compromised for the sake of speed. This is about delivering quality, but to do it in the most effective way possible.
Note
This is not yet clearly written to incorporate the reflect how this emerges from the constraints and constitutions above.
Contains the plan and all non-sensitive details of the system. Basically the system architecture.
Start of a new cycle.
Set the goal for the cycle.
The goal should be short and specific. It should be a observable outcome.
No details necessary. No speculations about how to reach the goal and what is required.
All that is necessary is a brief title of what is to be achieved.
The developer records central decisions, observations, hindrances etc during the cycle. Write it to support the later "Cycle Criticism".
Guidelines for the notes:
Write in present-tense objective style.
-
What was done? Why? What impact did it have?
-
dpfor decision points, -
pofor positive outcome, -
nofor negative outcome, -
//for comment,, -
ccfor criticism (for cycle criticism).
| Tag | Meaning | Use For |
|---|---|---|
dp |
Decision Point | Key choices, forks, trade-offs |
po |
Positive Outcome | Completed steps, successful implementations |
no |
Negative Outcome | Bugs, wasted time, failed ideas, regressions |
cc |
Cycle Criticism Trigger | Self-reflective note flagged for later criticism |
// |
Comment/Note | Neutral observations, clarifications, or context |
The last comments should be a "Cycle Criticism". The goal is to analyze the following:
- Time - Was the right amount of time spent on the right things, with regard to the goal.
- Are there things that could have been avoided entirely, or things that could have been done differently to save time?
- Decisions - Were the right decisions made, with regard to the goal.
- What could have been done better to reach the goal more efficiently?
- What in the developer's life, personality, habits, attitudes, beliefs, etc, contributed negatively to the outcome of the cycle?
Criticism of the critical process itself is also preformed:
Has the "Cycle Criticism" criticized the cycle honestly and rigorously from the point of view of a much higher standard than the developer's own?
- Articulate what would be an even higher standard of execution, and what it would require of the developer to reach that standard.
During the cycle, keep a self-critical mindset, and look out for things that can be subject to criticism. Record primarily the flaws in execution you observe, so it becomes material for the "Cycle Criticism".