Files
zmVault/estimating-dimensionality.md
T

1.9 KiB

id, aliases, tags, title, dg-publish
id aliases tags title dg-publish
destiny/uncertain
status/incomplete
topic/estimating
topic/organization
topic/software
type/idea
authorship/original
Estimating Dimensionality 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