emptiness
Occupied by a void
Roland Barthes wrote that the centre of Tokyo is occupied by a void...it is a quiet forest that lies at Tokyo's heart.
...The centre of Tokyo is certainly a void, but one that is protected by a circular train line, the Yamanote, which forms a 40-km (25-mile) loop around it. It seems to me that this ring of steel emphasizes the importance of the void, and the depth of its significance.
Names vs. The Nothing
This is the first site along the tour. In here we have a void. I remember the building that used to stand here, it was painted blue. Passing through it, you can imagine how us, as ghosts – should the building be standing here – would have to actually be invisible to pass through these walls and now it’s the reverse. The building is the ghost and we’re passing through these walls.
Erased de Kooning Drawing
Once, Robert Rauschenberg erased most of a drawing by Willem de Kooning, and then named it Erased de Kooning Drawing.
I am in no way certain what this is connected to either, but I suspect it is connected to more than I once believed it to be connected to.
Most important of all are the pauses
Japanese music is above all a music of reticence, of atmosphere. When recorded, or amplified by a loudspeaker, the greater part of its charm is lost. In conversation, too, we prefer the soft voice, the understatement. Most important of all are the pauses. Yet the phonograph and radio render these moments of silence utterly lifeless. And so we distort the arts themselves to curry favor for them with the machines.
Empty rooms
A Quote by Bruce NaumanI don't think empty rooms are ever really empty. I think we subconsciously put our emotions into them.
Software that nobody wants
Finding value is the result of enabling individual and group-level discovery attempts. It's not the result of everyone following one leader's gut.
What just happened is a new software product/feature was created that no customer wanted. This happens way too often. In fact, most hyper important software projects that must be done by date certain or else, have deep flaws that cause some variation of this phenomenon, flaws that include:
- Not wanted - Company specified a solution to a problem that customers don't actually have
- No Rarity - Company is pursuing an iKnockoff of existing products. The market already has two scaled competitors with working solutions, customers naturally spend budget on products that are already successful to avoid risk
- Incorrect Packaging - Customers need a website, but the company created an iOS app instead
- Incorrect Pricing - Customers need SaaS pricing, but the company created a shrink wrapped, on-premise solution with CapEx and maintenance agreements instead
The 'date scrum' anti-pattern
Date Scrum is an R&D pattern where developers are asked to estimate software project requirements upfront for the entirety of the project. After the project is green lighted and the budget is set based on the final estimates, the team then holds daily scrums to status and manage risk as they “iterate” the solution toward the release date. To some, this approach is described as doing Waterfall in sprints.
The fundamental problem with Date Scrum is that the team is de-focused from discovering the best solution. Instead they are heavily focused on delivering Something™ by the Date™. Engineers are problem solvers, and if the primary problem becomes delivering Something™ that will pass QA by the Date™, they will, with enough pressure, solve that exact problem.