#header-inner {background-position: right !important; width: 100% !important;}


Conditional Software Tiering.

Conditionality & Buddhism.


'Arise through the force of conditions'.

The meaning of Pratītyasamutpāda is that which arises in dependence upon conditions, in reliance upon conditions, through the force of conditions.

'This is, because that is.
This is not, because that is not.
This ceases to be, because that ceases to be.'


Conditional Software Tiering.

i think it's possible to give Software such a quality.

to depend on conditions, perhaps on surplus, including reserve components, so it's more robust, sturdy & secure... in case of a single component failing, we can use other, spare ones... this is nothing new in Software Development, i think.

software can detect & report which software components are operational, assemble itself from such, upgrading functionality to higher layer if possible, and in case of component malfunction(s), reducing itself to more basic functionality as needed.

because proper working of components are preconditions for proper working of other components which arise from such.

higher layer functionality reduction can also be caused by other conditions such as need of resources for other causes & software parts, including security on a 'different front'.

Conditions & Causes.

there can be that something arises because of a cause(s) occuring, while precondition(s) hold. cause(s) occurance can be modelled using event(s), conditions holding or not can be represented as a data in the database or tuple(s) in the Tuple Space.

ceasing of conditions or arising of conditions might also be events that's how decisions can be made for software to advance to higher tiers or to degrade itself to lower functionalities as neccessary.


see also, if You wish: Conditions, Security Harness, Software Complexity, 'Events' in Programming, Conditionality, Token Game.


  1. (PL) Warunkowe Skalowanie Oprogramowania. (im wyższy poziom skali, im wyższa warstwa funkcjonalności, tym więcej jest zużywanych zasobów obliczeniowych - przede wszystkim czasu procesora i pamięci operacyjnej).

  2. (PL) Oprogramowanie jest uwarunkowane - zależy od bardziej podstawowych, prostszych części, często programów niskopoziomowych... ale też od sprzętu, elektryczności, być może czegoś jeszcze...

  3. (PL) To że oprogramowanie zależy od czegoś nazywamy zależnością oprogramowania od warunków. Oznacza to że zarówno samo działanie oprogramowania (czy działa) jak i sposób działania (jak działa) zależy od warunków, lub inaczej - od zależności (oprogramowania). jeśli zmienimy zależności oprogramowania, właściwości oprogramowania ulegają zmianie, na tym polega haking, na przeróbkach, dodawaniu funkcjonalności itd...

  4. (PL) brak kontroli nad zależnościami w kodzie (programie komputerowym) kończy się często degradacją jakości kodu, z czasem większymi kosztami utrzymania kodu, i błędami w działaniu, lukami itd... innymi słowy chaos w zależnościach powoduje że aplikacja się wali. kontrolę nad zależnościami w kodzie można opisać tak: które komponenty (części) oprogramowania współpracują z którymi, i jak... nadmiar zależności to problemy.

  5. (EN) there can be 'solutions' that remove preconditions of competition's success. then perhaps resources can be claimed that way for us.

  6. An interesting idea, however you have missed on some of the more important aspects of Pratityasamutpada, especially within the remit of Candrakirti's Madhyamaka Prasangika.

    Namely, not is there a dependency upon condtions, but there is also a dependency on designation. This is a fundamental issue in software, in that we must construct (designate) our models in accordance with the business domain rather than our own pre-conceived notions about the 'way things are'. Not only that, but the choice of names in programming is directly correlated to the ability to identify meaning in the software.

    A third dependency is that of the relationship between an object and it's parts - yes, this is all 8th Centuray philosophy. So the interelationship of an object to it's parts (unable to function as the object as defined without having required attribues.) is likewise an extremely important aspect to software programming.

    Regarding dependency on causes, note that, at the design level, this has some sort of sense in terms of instantiation - objects depend upon required needs (circumstances) in order to be instantiated.

    Not surprising that many coders follow some sort of Buddhist philosophy.

    Of course, although such principles make us great coders, the purpose (or motive) in Buddhism is to help us eliminate the reifying view that tends to get us to invest all our energy in that which is only ephemeral and completely dependant upon causation, designation, and composition - namely our selves.

  7. thank You unknown commenter.

    had insight that i am beginner, 'stream enterer' on Buddha's Way.
    i do not understand many things as of yet.
    perhaps someday i will.
    i wish to return to this post by then,
    but not at all cost.

  8. After reading a part of HH Dalai Lama's book about Emptiness, Interdependent Origination and Illusory Nature of Reality i returned to this article.

    i'll think more on dependence on the parts and on cause.

    thanks for this valuable comment, Mr. Unknown.

    probably will use 'Token Game' methodology to model conditions (represented by tokens) & causes (represented by events).