a map

[ArtemGr]

(_Software development might be oft represented as a spatial structure. There is oft an implicit feel of that structure, and it pays for the Architect to communicate this structure clearly, to create a spatial representation of it that allows everyone to orient at a glance
It will also allow for tracking and sharing the team cohesion: namely, where the members are, and where they want/need to be
Interestingly, this spatial representation might be very similar to the rooms in Interactive Fiction ( https://en.wikipedia.org/wiki/Interactive_fiction#Medium; http://brasslantern.org/writers/iftheory/roomasmetaphor.html ). And the IF metaphor might hopefully communicate to the players the tradeoffs of working in concert or venturing somewhere alone (we can assign the various danger and Schrödinger tags to a room, silimar to how games assing a level to an area or a quest)_

reminds me of Сапковский Анджей: Без карты ни шагу)

Known kinds of rooms so far: tracing, interoperability, modularity, stackoverflow, testing and simulation, no_std, optimization, linux kernel, stable api

p.s. Ideally the graph of rooms would be replayable too, allowing one to see a history of what's been going on, who worked on what, when and how the map was changing.. A simple implementation of that might be to add new iterations of a map as new sections of a document

p.s. (The map and the numbers attached to it might serve as a form of Deliberate Practice, of finer-grained measurement and representation of a progress. It might counter the spoiling of a plan (Hagakure: “When matters are done leisurely, seven out of ten will turn out badly”), similar to how outlining a novel counters the dangers of writer pantsing. As such, it might reduce the need for desperateness
There is, of course, a certain danger of getting the map too far, all the way to the Waterfall. As with the novel outlining, the mapping works if it allows for greater flexibility in rearranging the rooms and in course-correction. With a map one has only to update or to draw a new one in order to get the team up to speed regarding the course corrections, whereas without the map the outdated orientations risk to explode the complexity)

[ArtemGr]

Experimenting with the idea of "writing terrible stories": https://observablehq.com/@artemgr/rusty-gun-a-story https://youtu.be/e2pLGyji1Fc

[ArtemGr]

Been thinking about the Value Stream Mapping in Lean, but with a twist.

If we look at it from the side where things are happening, where we design and develop (instead of looking at it from the side of a customer) then the Value takes a slightly different shape.

First, in an open source project the developers are also the customers. Indeed, we are the customers who found something not being present on the market and decided to help with implementing it. And different customers have different understanding, different vision of Value. For @GiraffeKey the browser WASM was of Value, for @ArtemGr the raw WASM is of Value, as well as the Linux kernel support. In a typical Lean setup we have a number of leader figures (Product Leader, Technical Leader, Functional Leader) who communicate with the customers, prioritize between the needs of the market and focus the team on this or that vision of the Value. One of the reasons for such prioritization is to market one kind of Value faster. It is a question of ping (response time) versus throughput. With Value Stream Mapping we optimize for the ping, in order to get ahead of the market and start netting the customers. Other approaches optimize for different things. Set-Based Design might be optimizing for quality and fitness of the resulting software, pitfall avoidance? Pull might be optimizing for throughput, encouraging developers to work on what they deem currently a best fit for them?

(Interestingly, Poppendieck mentions how all the successfull teams that she've seen has developed their own processes. So the textbook approaches are just the templates to borrow from. In PDIA terms, imported solutions only work best for the simplest or problems, optimizing software development process is oft not one of them. That is also why I want GUN to be super-modular and super-transparent: for it to be a reusable toolset in constructing domain-specific solutions, rather than another black box).

Second, if we look at the project from the developer persective then Value is basically Motivation. Calling for Motivation Stream Mapping.

[ArtemGr]

Figured the map for now. Will keep tracking the bounty and freelance progress in 12-map.md though

[ArtemGr]

Going to continue with maps at https://observablehq.com/@artemgr/path

[ArtemGr]