vault backup: 2025-10-10 14:37:17

optimal-estimating-patterns.md

@@ -0,0 +1,157 @@
+---
+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.
+
+## Flaws of Traditional Patterns
+
+### Required Hyper-Specificity
+
+The reason that it's such a big deal to change between 1-hole straps and and unistrut straps
+is because it takes so long to do.
+If it was as simple as it is to visualize,
+which it could be if you were drawing these things and it was being interpreted,
+rather than having to explicitly specify every aspect of what you wanted.
+Then that would make a huge difference.
+
+In the (granted, limited) market segment that we've worked in,
+I use ~10 assemblies on a regular basis.
+That makes up 99% of the work.
+Why are there hundreds in in our database?
+They just need to be better.
+You could probably get away with hard coding some of this,
+even if that irks me,
+if they were good.
+It's just that it doesn't seem to be a goal
+that Trimble or anybody else has.
+
+### Assumed Finality
+
+While they may support a multitude of creative methods to create takeoffs,
+traditional methods are rarely as convenient when it comes to modify those takeoffs,
+as is frequently necessary as in the case of mistakes and revisions.
+
+## 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.
+
+#### Project Structure
+
+Organizational info (items, assemblies) as submodules.
+Solves database conflicts by pinning estimates to a commit.
+
+[[breakdown-objects]]
+[[assembly-objects]]
+
+### Sketch-Based Lookup
+
+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.