Intelligent design

This post presents intelligent design as a resonance on the crystalline structure of the universe and follows the context of a previous article on the subject.

The concept of resonance allows to understand the crystalline structure of the universe, on one hand, and the idea of intelligent design in the universe on the other.

Firstly it is necessary to clarify that we do not have any conscious experience of time whatsoever. We only perceive time by comparing different moments. In this sense, we exist in a single moment in time, the so called “here and now”. Which is the same as saying that this is the way by which everything is presented to us, hence the common saying that reality is the here and now. But it is asserted that that is not a portrait of reality but instead our perspective of reality.

Now if something exists independently from the perception of its existence, then it has to exist in time, that is, it cannot by itself cease to exist. Due to the fact that our perception is time-less, from the PoV of this perception this impossibility of the (future) inexistence of something is a retroactive consequence in time. That is, it is a consequence of something that is established after its perception.

This is where we gain the perception of intelligent design, that is, the consciousness of future states of which the current state is a cause.

In reality there is no design a priori but the perception of a design.

This can be defined, from the perspective of the perception of something, as a resonance in time, that is, a constructive interference in at least one dimension of the universe (in this case, time).

This applies to something that exists at any moment in time, therefore what exists at some point in time has always existed and always will exist. This demonstrates the crystalline structure of the universe, since there is nothing that is left to add to the universe. Everything that exists is a resonance in a crystalline structure, that is, a complete and immutable structure.

The perception of the universe adds to the dimensions by which it is perceived at least one other dimension, that of the subject of perception. The subject can perceive himself, therefore the universe is perceived as infinite-dimensional. therefore, either the universe is a-dimensional or it is infinite-dimensional. What here is said regarding time applies to the perception of the universe in any N dimensions relative to the (N+1)-th dimension.

Another way of looking at this is the fact that the number of possible configurations of any system increases exponentially with the number of its constituent parts. Therefore, more complex systems are more likely than otherwise (this likelihood spawns from the resonance mentioned before). The law of entropy still holds, but at a subsystem level. At a super-system level it is superseeded.
This explains the order on the universe, and that the disorder is in reality an affirmation of the different (infinite though countable) possibilities of order.

All this does not mean that God does not exist but rather that, if it does, we are certainly a part of it. It is not an entity distinct from its creation. It is THE creation, both as an object and as an action.

Meditation as a form of creation

Nothingness, since it cannot define itself, is a definition of the existence of something. This something is indeterminate, that is, this definition underlies everything that exists.

Therefore, defining nothingness is to create everything that exists. [1]

Meditation, as a form of defining nothingness, is a form of contemplating the creation, and a form of creation.

If it does not itself change reality, it allows to create a perception of reality.

From nothing… everything.

_______

[1] this is isomorphic to the concept of inversion dealt with on previous posts

All in All

I have spent a few days exploring what has been termed a very complex problem.

This type of problem was in some ways familiar to me and I applied a variation of a technique I used before in my work on True Machine Learning.

Although I didn’t solve the problem, I was able to formalize it in precise terms and I was very pleased with the fact that this formalization relied on what is a graph theoretical version of the known philosophical principle all in all.

I created a property of a node in a graph that is described in terms of the geometry of the entire graph to which it belongs, relative to the place this node has in it. This means that the entire geometry of a graph has a version of it described from the point of view of each of its nodes.

The whole is reflected in each of its elementary constituents.

And that is beautiful.

Praia Grande

Images from Praia Grande in Sintra, Lisbon, Portugal.
This is the beach where I learned to surf about 19 years ago.

Mahler: Symphony 5, IV. Adagietto, Sehr langsam
Orchestral (original) version alternated with the transcription for piano.

Alto Giove

The power of Art to uplift us from darkness.
Credits in the video.

Its worthy noting that the singing voice was a synthetic blend of two voices, that of soprano Ewa Malas-Godlewska and counter-tenor Derek Lee Ragin, to achieve the perfect androgynous voice of the 18th century castrati opera singers.

Invariant factor decomposition for finitely generated modules over a Principal Ideal domain

Proof of the existence (1) and unicity (2) of the decomposition.
As usual, the only thing relevant here is the music score, but you go ahead and spend 20 minutes dumbing yourself down like the good ideological peasant that you are. The trailer trash nobodies who profit from this will tell you its a “higher” form of education.

music:
Mozart Concerto for Piano and Orchestra No. 20, I. Allegro and II. Romance (excerpt)
Mitsuko Uchida; English Chamber Orchestra, Jeffrey Tate

What does it mean to “be agile”?

Even as a traditional business analyst, I can be more agile than a agile purist.

This is to make you understand the problems you incur when you simplify complex realities down to a small set of buzzwords and prescriptive practices while not questioning nor understanding those realities. You may actually end up doing the precise opposite of what you claim and wanted to be doing.

I can spend more than a month just in requirements elicitation and analysis — the agile purist nightmare.
At the end of it, I produce my deliverable which is a functional specification. This is a formal, highly structured document that is meant to explain to anyone interested in the project what is to be achieved (but not how, despite some functional constraints can limit those possibilities) as well as to secure the commitment of the business towards the project. This is also called the scope for the projet, that is, the set of things that the delivery team will be working on, or equivalently what the technical deliverables will look like to the customer who will receive and use them.

Delivering a functional specification at the end of a say 6 week work timeline is in accordance with the agile principle “document late”. This principle means to delay as much as possible commitments (in this case, scope commitments), when we will be more certain and have more information about what those requirements are.

During that period, and besides getting the requirements, my focus is in securing alignement between all stakeholders throughout the process.
In the mean time I am not “building” my deliverable, I am using artifacts that help me accomplish these goals. They can be a range of artifacts, but they all have in common that they are meant to evolve with the interactions with the stakeholders and they do not provide any guarantee to any stakeholder regarding team commitments.
These are the artifacts (or the “working deliverables”) that I exchange with the stakeholders. Unlike a formal project deliverable, such as a functional specification or a minimum viable IT solution, they are not meant to be approved by anyone.
The feedback they ask for is intented to adjust those deliverables until the conditions are met for a formal commitment by the team regarding the scope.

An agile purist would in abstract do exactly the same thing as I did here (so you see how the distinction agile/traditional is in this case misleading and atcually meaningless), with one main difference however: he would use formal project deliverables to elicit feedback.

The implication of this is that

I do not incur the overhead of actually implementing a (minimally viable) solution
I can adapt to change in requirements easier because they impact working deliverables meant to evolve just-in-time
I am sharply focused in promoting alignment between stakeholders and commitment on their part to the project, which protects the whole team
I defer the delivery team commitment to the very last responsible moment when it can be done with the least cost
I clearly separate in the project timeline two very different things which are the alignment between business stakeholders (a focus during analysis) and the alignment between those and the delivery team (a focus during implementation), thus making it more easily manageable and reducing risk

Due to this, I am more agile as a traditional business analyst than an agile purist. So you see, its not the fact that I am a business analyst that prevents me from being agile and even more agile at that compared to someone whose role title or prescription is “agile”. Although I am also formally a (Disciplined Agile) Scrum Master.

This is also in accordance with a (PMI) Disciplined Agile principle, which is that our focus must be in achieving agility, not in following a specific practice or methodology.

From the point of view of the delivery team, one could argue that the priority would be to get early feedback from stakeholders regarding architecture, usability, and other characteristics of the implementation deliverables that are not in the scope of a functional elicitation, however this is always bound to the necessary precedence between models or designs (requirements) and their implementation (IT solutions). You can do it at the same time, in certain circumstances, but that adds the overhead of evolving two very different types of deliverables at the same time with the waste injected by having to make corrections twice instead of once. On the other hand it doesn’t necessarily assure you a quicker elicitation of requirements.

As an example, I had a junior analysts team with me in a project once. I gave them guidance about this subject and in particular I explained them the differences between a formal specification and the working document I was proposing them to use during elicitation.
As I expected, the project manager prompted them to deliver the specifications in the usual two week agile timeframe. They chose to deliver the formal specification while I was constantly delivering the working document in my elicitations (that is, I was not formally delivering but instead I was extending the iterations duration to adjust to my needs, which is a totally valid Lean managment approach). The overhead for them of having to constantly change the formal specification and to explain it to the customers, and the overhead to the customers of having to approve successive versions of the documents, made them extremely inneficient, made the customer weary and insecure in trusting the team’s work quality, to the point that in the end I alone managed to secure more scope than they did altogether, even considering the difference in seniority. In reality, lesser seniority in analysis should point them to work on more simple artifacts, just like I proposed to them. Following a 2-week delivery cadence just for the sake of its name should have been secondary to them, despite being paramount to a project manager with very little analysis skills.

This is a practical example. Of course, I took care to explain to them that in the future, if they will be working as analysts, they should behave as such and not as a project manager trainee with little knowledge of managing stakeholders for business analysis. Therefore, instead of blindly following a project manager’s orders, which is in itself anti-agile because it is prescriptive, they could instead follow the informed advice (which is agile) of more senior practicioners. And thus be more agile than agile purists themselves.

Bedtime Story

This is an ancient betime story. It was passed down from generations.
And now its your turn to learn about it and sleep as an angel.

Sources:

Violin Sonata no 1 in G minor by J. S. Bach (excerpt)
Queen of Winter Throned by Cradle of Filth (excerpt, 1994)
There Shall be no Darkness by James Blish (excerpt, 1950)

Fringe Mathematics

The Devil’s Advocate

Everything falls apart and the devil is behind it all.
Excertps from the movie “The Devil’s Advocate” directed by Taylor Hackford (1996; IMDB).

____________
This recording is kept for historical reasons since it is not recent and I am practising & improving everyday. It is about the development process, not the actual technique.