"The times" of considering the system ​

If something is done, it is usually done as part of a project to change some piece of the world. This means that some system is created and/or developed (the difference here is small, "from scratch" or "by modernizing an existing one").

So any work is part of some project, and any project is part of the work of creating and developing some system (of course, the creation and development of some system can include various projects, including independent ones. One project planted a tree, another project discovered it after a hundred years and took care of it, a third project discovered the tree again after another hundred years - and cut it down). Old phrases like "in the course of the X system life cycle" can be said as "in the course of creating and developing the X system", and often the "development" is even omitted (today, creation without development is rather an exception), so "in the course of creating the X system".

In discussions of various projects for creating and developing systems, there are many explicitly defined times that should be considered in projects:

1. Run-time/operations, it is at the development stage from scratch, as well as the development of features (modernization). This is the time of operation of an existing target system. It is often in the future, so it is necessary to think of the system as already existing and successful (i.e. meeting the needs of project roles, or even exceeding their expectations). The run-time can be very short, for example, 20 milliseconds for executing some software or an explosion. It can also be three minutes for a dance performance, or eighty years of uninterrupted operation of a nuclear power plant unit. At this moment, the system is ready (it is in the physical world, configured and operational), it interacts with its environment, bringing irreversible benefit to this environment through its use. The explosion destroys everything around it, the software processes data, the dance performance takes place and pleases people for three minutes, the nuclear power plant unit generates electricity. The leading aspect of examining the target system here is functional, while system creation is usually not considered (but can be considered by the operator who works exactly at that time).
2. Design and construction time as the work time of the creator of the target system, where the target system's state is not necessarily operational - in fact, it may not even exist in the physical world. This is the design-time or development in IT (starting from conceiving and including the "continuous everything"), but it also includes manufacturing time, tuning, testing, commissioning, modernization, and maintenance for "hardware systems", which is often not considered as separate tasks in software engineering. The safety airbag controller software runs for 20 milliseconds, but its design and construction time was three years for the initial version and three years of operation (where actual activation is only 20 milliseconds, the rest is waiting time), but not just six years, but much more - because every year a new improved version comes out, and this has been going on for twenty-five years, and it is unclear how long it will continue ("continuous everything" in technical evolution may be limited in time, but in general, the development of life, including the technosphere, is endless). This time can be divided into the total creation and development time (evolutionary/development) and the time of creating and debugging a single version or feature of the system (increment creation time), considering that the development time consists of creating multiple increments, but these are already details. The main point is that we are talking about examining the work of creation systems and states of the target system that is not operational yet. The leading aspect of examining the target system at this time is constructive, while the leading aspect of examining the system creation is functional (roles and practices).
3. Methodological time (discussions of "how to do it"), taken outside of projects - the time of creating by the creators of the target. There can be several methodological times: the founder of the company works during the founding of the company, the organizer of the engineering team, which was created during the establishment, then works during the organization of the engineering team. This is beyond project time, it is the most challenging time (and even multiple times, because there are multiple "systems creation and development" as chains of creating a single system and exceeding these chains for current projects), but it is easy to understand if you refer to the idea of space-time, in which by definition systems (target, in the environment, creation) have neither "already" nor "yet", they all exist simultaneously. In methodological time, we think about both usage time and creation and development time, we think about culturally conditioned (beyond the project) methods/practices, we think about refining meta-models and meta-meta-models. We think about the project beyond its limits (even if we are deeply involved in the project ourselves), we engage in methodological work: we think about the working method, how to work, how to organize the project, rather than working in the project. And this is usually thinking about the future, and even the "indefinite, unclear future", because you can only assume/project how it will be there, but you cannot guarantee what will actually happen in that future. So you, reflecting on your work project and your place in it during this course, are in methodological time, and when you perform the tasks of this project, you immediately find yourself in the time of creation and development. Methodological time is sometimes called reflection time, but reflection is a look into the past, at actions that have already taken place, while methodological time assumes consideration of both the past and the future. There are no leading aspects of examination here because all aspects are presented for various systems. Methodological time is easier to imagine as the time of viewing and discussing a certain film "creating and developing a system" right before your eyes. In the European tradition, the timeline of this "unfolding in time of movie frames" is presented at eye level from left to right as frames in a film reel (but these are not frames, they are scenes, "gifs"), and you can observe the whole film throughout, just by turning your head, looking at different parts of this film. Of course, the film "creating and developing a system" could take a decade before such examination, then it could penetrate the future for another decade (it is easy to imagine a film showing the future!). But it is also easy to imagine a film passing before your eyes from front (future ahead) to back (past behind). Then what is right in front of you "here and now" occupies your entire field of view, the future is not visible and therefore is not taken into account in actions, and the past has already passed and therefore is not taken into account in actions. Examination of methodological time is lost, you are actually only in the current frame, at some point in the time of creation and development or even in the time of operation.

One must be able to switch between these times, pay attention to all these times, manage attention to maintain reasoning related to these times. Especially difficult here are the run-time (thinking about the future, thinking about what is not there yet) and methodological time (requires some detachment from immersion in the current situation), more often people in projects get stuck in reasoning about creation and development time - so extraordinary efforts are needed to discuss the functional aspect of the target system (not the constructive one), the environment of the target system (during operation!), as well as long chains of creation and their culturally conditioned practices (this is usually methodological time).