155 lines
4.6 KiB
Markdown
155 lines
4.6 KiB
Markdown
---
|
|
id:
|
|
aliases: []
|
|
tags:
|
|
- authorship/original
|
|
- destiny/fleeting
|
|
- status/incomplete
|
|
- topic/estimating
|
|
- topic/software
|
|
- type/idea
|
|
title: Optimal Estimating Patterns
|
|
---
|
|
# Optimal Estimating Patterns
|
|
|
|
[[construction-estimating-software]] consistently fails to innovate
|
|
on the stale patterns developed for marginally similar applications decades ago.
|
|
|
|
## More Optimal Patterns
|
|
|
|
> [!note]
|
|
> Note that while the patterns described below
|
|
> _are_ more optimal than those of traditional applications,
|
|
> the bigger problem with such applications
|
|
> is their suboptimal implementation of their patterns.
|
|
> If you could just do what they're trying to do correctly,
|
|
> you probably wouldn't need all these optimizations anyway.
|
|
|
|
<!-- TODO:
|
|
|
|
Count-based takeoff speed increases with count.
|
|
|
|
Optimizing the takeoff process means:
|
|
|
|
* _Minimizing_ the need for information outside of drawings
|
|
* _Maximizing_ organizational consistency
|
|
|
|
-->
|
|
|
|
## More "Innovative" Patterns
|
|
|
|
These ideas are farther out there
|
|
in terms of what existing estimators may be willing to accept
|
|
|
|
### Estimating As Code
|
|
|
|
#### Compared to Existing Frameworks
|
|
|
|
Traditional methods interact with an existing database.
|
|
EaC builds a static database at runtime,
|
|
allowing flexibility of input.
|
|
|
|
* define variables
|
|
* search and replace
|
|
* undo
|
|
|
|
#### Project Structure
|
|
|
|
Organizational info (items, assemblies) as submodules.
|
|
Solves database conflicts by pinning estimates to a commit.
|
|
|
|
#### Related Notes
|
|
|
|
* [[breakdown-objects]]
|
|
* [[assembly-objects]]
|
|
* [[functional-labor-factoring]]
|
|
|
|
### Bayesian Takeoff
|
|
|
|
#### User Story
|
|
|
|
Frank is estimating a 20-story high rise
|
|
and notices that their are roughly, but not exactly,
|
|
the same number of receptacles in the corridors of levels 2 to 19.
|
|
Frank starts a new takeoff for duplex receptacles,
|
|
typical of levels 2 to 19.
|
|
He counts and inputs quantities for 3 levels,
|
|
each adjusts the prior to calculate the expected quantity for all 18 levels.
|
|
|
|
### Sketch-Based Lookup
|
|
|
|
<!-- TODO:
|
|
This section is a transcription of a dictation.
|
|
To be condensed.
|
|
-->
|
|
|
|
A better use for computer vision in estimating
|
|
is sketch based assembly lookup.
|
|
Probably the the biggest hang-up in the workflow
|
|
is searching through available assemblies and items based on text,
|
|
which has a number of problems,
|
|
mostly that names, in electrical material for certain, are practically meaningless.
|
|
|
|
Trade names are incorrect, and there are often many different names for the same item.
|
|
Basically, there's just so many problems with text-based lookup as a rule.
|
|
That sketching and handwriting recognition would be more idiomatic.
|
|
|
|
Drawing lines for raceways, angles representing bends,
|
|
squiggly lines representing flexible conduit, etc.
|
|
All things that are common sketching conventions
|
|
that estimators are probably drawing in their workflow anyway.
|
|
|
|
Many parts of the estimating workflow would be greatly benefited
|
|
by the sort of non-traditional interface that Ink & Switch promotes.
|
|
Traditionally estimating software is all tables and forms.
|
|
|
|
Suppose you were to sketch a takeoff indicating a run
|
|
|
|
1. from a panel
|
|
2. up to the ceiling
|
|
3. across the building
|
|
4. down to a disconnect
|
|
5. out through a flex connection
|
|
6. to a piece of equipment
|
|
|
|
that's a very complex assembly,
|
|
and despite how common it is,
|
|
it can be very difficult to to get exactly that from databases.
|
|
|
|
Suppose instead you draw that that sketch
|
|
and the application creates a graph
|
|
of all the primitive parts of that assembly.
|
|
|
|
It may include the panel and the equipment by default
|
|
but with the same stylus you used to draw the sketch,
|
|
you just cross out the panel, the equipment,
|
|
the parts that that you didn't intend to include.
|
|
|
|
1. Draw a line from start to end.
|
|
* A canvas appears on top of the plans.
|
|
2. Sketch the desired assembly with predetermined conventions.
|
|
3. Draw a checkmark to confirm
|
|
* A render of the interpreted assembly appears
|
|
4. Draw a second checkmark to select.
|
|
|
|
A Non-Traditional Computing approach
|
|
(journal-type, heavy-stylus-use),
|
|
would would be great here, too.
|
|
|
|
Keyboards as a takeoff input device are an anti-pattern.
|
|
Every time you're entering data is an interruption.
|
|
|
|
But perfect for that would be drawing takeoffs on the on the prints
|
|
then using stylus based interaction patterns to edit them.
|
|
Lasso selecting groups of takeoffs to change aspects of them.
|
|
|
|
There is so little typing necessary.
|
|
Everything that you're typing is just short descriptors
|
|
that, in a lot of cases, don't even need to exist.
|
|
the language exists purely to roughly communicate ideas
|
|
that are intuitive in even a crude sketch.
|
|
|
|
Estimating is a perfect use case
|
|
for a purely stylus and handwriting recognition based workflow,
|
|
probably more perfect than whatever Ink & Switch is using.
|