Files
zmVault/estimating-dimensionality.md
T

86 lines
1.9 KiB
Markdown

---
id:
aliases: []
tags:
- destiny/uncertain
- status/incomplete
- topic/estimating
- topic/ergonomics/organizational
- topic/software
- type/idea
- authorship/original
title: Estimating Dimensionality
dg-publish: true
---
# Estimating Dimensionality
## Flaws of Traditional Estimating Methods: Enforced Linearity
Something that I've realized that really bothers me
about the the traditional methods
(e.g. database-based takeoff, audit-trail-type-abstraction)
is the the _enforced linearity_,
which is at odds with the reality of takeoff.
No matter how you slice it,
the user is thinking about your takeoff in some linear fashion.
Whether it's the takeoff creation date, or however they've sorted it,
Really date is the only useful measure,
but it's also useless, because you forget stuff.
The fact that forgetting something
totally disrupts a previously logical timeline of takeoffs
means that you stress about every single takeoff;
Instead of being in a flow state,
you have to be thinking 10 steps ahead.
I mean, I do, because I care about that sort of thing.
I suppose other people may not be as concerned,
but that doesn't really justify it.
The problem is that there's nothing linear about electrical installations,
at best it's a directed acyclic graph.
You can almost represent that linearly
if you go down each branch to the end
and then pick a new new line,
but that's unideal.
## Spatial Indexing
Scope exists in a three-dimensional space,
more if you suppose phases and bid options
as having a position on time and decision space axes respectively.
The most idiomatic alternative to time-indexed takeoffs
would be to represent them in the space of the drawings,
then only extend them as necessary.
### Generic
Negative <-> Positive
Previous <-> Next
### Space
Down <-> Up
Out <-> In
Left <-> Right
Backward <-> Forward
West <-> East
South <-> North
Ana <-> Kata
### Time
Past <-> Future
Prin <-> Kat
Before <-> After
### Option