ZaneMeyers/zmVault
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

vault backup: 2026-01-11 12:50:45

Browse Source
This commit is contained in:
Zane Meyers
2026-01-11 12:50:45 -05:00
parent 025adb476c
commit 76479bcedd
17 changed files with 250 additions and 107 deletions
Download Patch File Download Diff File Expand all files Collapse all files
2026-01-11.md
+67
View File
@@ -0,0 +1,67 @@
---
id:
aliases: []
title: 2026-01-11
tags:
- authorship/original
- destiny/permanent
- status/draft
- type/daily
---
# 2026-01-11
## 2026-01-11 09:00
[[2026-01-09#2026-01-09 14:45]]
[[bid-price-modeling]]
[[decrease-in-sigma]]
## 2026-01-11 11:00
![[favorite-quotes#"It Takes an Engineer to Build a Bridge that Barely Stands"]]
The value that estimators provide for a contractor
is in modeling project cost.
If the goal were simply to present a number the cost will not exceed,
than anyone could be an estimator.
If the goal were only to present a reasonably accurate figure,
with no other constraints,
then there are few who in the world who couldn't,
given infinite time for a single bid.
The _true_ value of an estimator, then,
is in their ability to model project cost _efficiently_, that is,
to achieve acceptable accuracy and precision as quickly as possible,---
much as the engineer's is in building a bridge that _meets_ the requirements
as cheaply as possible.
Estimating "as accurately as possible"
is akin to building a bridge "as strong as possible";
it sounds nice, but ignores the actual objective of _optimal cost-efficiency_.
I think that most estimators believe this to be the case,
but, whatever they believe in mind, they believe in practice
that the goal is to model cost as accurately and precisely as possible,
_given the time allowed for bid_.
Estimates tend always to take exactly as many weeks as until the bid due date,
even those of significantly different turnaround but equal scope and complexity.
This behavior is objectionable,
since if an acceptable estimate _could_ be provided in two weeks,
it is not cost-effective[^1] to allow it to take four.[^2]
[^1]: "Cost" referring both to estimator salaries and the opportunity cost of declined bids.
[^2]: Supposing a contractor maintained a modern portfolio theory styled record
of estimates including pending bids, and projects ongoing and completed,
with confidence estimates uncorrupted by [[estimating-culture#Incentives|perverse incentives]],
they may have reasonable basis to set sliding standards for estimate precision
to be specifically determined at consideration of the opportunity for bid
according to current climate (i.e. their risk appetite).
I believe my use of the absolute is still fair.
No contractor is doing that, so they lack a competent measure of risk tolerance
besides continuing to tolerate what they have historically.
Objectionable as it is,
it is to be expected that estimators will use all time allowed them
when the standards for _acceptability_ are inadequately defined.
actuarial-science-for-construction-estimating.md
+1 -1
View File
@@ -23,4 +23,4 @@ In this way, projects are better compared to _insurance accounts_.
* cost of individual service is uncertain
* cost to customer must be minimized
![[decrease-in-sigma#^pdf]]
![[decrease-in-sigma#Normal PDF]]
bid-process-strategy.md
+1 -1
View File
@@ -1,5 +1,5 @@
---
id: risk-oriented-estimating
id:
aliases: []
title: Bid Process Strategy
tags:
consolidate-estimating-thoughts.md
+5 -1
View File
@@ -17,6 +17,10 @@ are currently disparate, disjointed, and redundant.
## TODO
### Supertopic: Risk-Oriented Estimating
Still deciding if I'm capable of being opinionated without rambling.
### Legitimate Subtopics
* [[estimating-methodologies]]
@@ -40,7 +44,7 @@ Create and use cross-topic notes for complex thoughts:
* [[bid-process-strategy]]
* [[game-theory-for-construction-estimating]]
* [[estimating-culture]]: estimator incentives
* [[estimating-culture#Incentives]]
* [[project-management-for-construction-estimating]]
* [[separating-estimating-concerns]]
construction-estimating.md
+1
View File
@@ -40,6 +40,7 @@ For philosophy see [[bid-process-strategy]]
* [[auction-theory-for-construction-estimating]]
* [[game-theory-for-construction-estimating]]
* [[project-management-for-construction-estimating]]
* [[utility-in-construction-estimating]]
* [[ambiguity-in-construction-estimating]]
* [[nontraditional-computing-for-construction-estimating]]
* [[object-oriented-programing-for-construction-estimating]]
decrease-in-sigma.md
+56 -45
View File
@@ -11,6 +11,8 @@ tags:
---
# Decrease in Sigma
## Normal PDF
```tikz
\usepackage{pgfplots}
\pgfplotsset{compat=1.16}
@@ -47,53 +49,62 @@ tags:
\end{document}
```
^pdf
## Lognormal PDF
```tikz
\usepackage{pgfplots}
\pgfplotsset{compat=1.16}
![[lognormal-pdf.gif]]
\pgfmathdeclarefunction{erfapprox}{1}{%
\pgfmathparse{%
% save sign and work with |x|
( (#1<0) ? -1 : 1 )
* ( 1 - (1 + 0.278393*abs(#1) + 0.230389*abs(#1)^2 + 0.000972*abs(#1)^3 + 0.078108*abs(#1)^4)^(-4) )
}%
}
%%
```python
import numpy as np
import matplotlib.pyplot as plt
from scipy.stats import lognorm
import imageio.v2 as imageio
import os
% Normal CDF using erf approximation:
% F(x;mu,sigma) = 0.5*(1 + erf((x-mu)/(sigma*sqrt(2))))
\pgfmathdeclarefunction{normcdf}{3}{%
\pgfmathparse{ 0.5*(1 + erfapprox((#1-#2)/(#3*sqrt(2)))) }%
}
mean_target = 10.0
sigmas = np.linspace(1.0, 0.1, 25)
x = np.linspace(0.001, 40, 2000)
\begin{document}
\begin{tikzpicture}
\begin{axis}[
width=13cm,
height=7cm,
axis lines=middle,
xlabel={$x$},
ylabel={$F(x;\mu,\sigma)$},
xmin=-6, xmax=6,
ymin=0, ymax=1.05,
samples=400,
domain=-6:6,
legend style={draw=none, fill=none, at={(0.02,0.98)}, anchor=north west},
legend cell align=left,
ytick={0,0.5,1},
]
% Normal CDF: 0.5*(1 + erf((x-mu)/(sigma*sqrt(2))))
\addplot[thick]
{ normcdf(x,0,1.8) };
\addlegendentry{$\mu=0,\ \sigma=1.8$}
\addplot[thick, dashed]
{ normcdf(x,0.8) };
\addlegendentry{$\mu=0,\ \sigma=0.8$}
\end{axis}
\end{tikzpicture}
\end{document}
# Precompute global y-limit
pdf_max = 0.0
for sigma in sigmas:
mu = np.log(mean_target) - 0.5 * sigma**2
pdf = lognorm.pdf(x, s=sigma, scale=np.exp(mu))
pdf_max = max(pdf_max, pdf.max())
frames = []
tmp_dir = "frames"
os.makedirs(tmp_dir, exist_ok=True)
for i, sigma in enumerate(sigmas):
mu = np.log(mean_target) - 0.5 * sigma**2
pdf = lognorm.pdf(x, s=sigma, scale=np.exp(mu))
plt.figure(figsize=(6, 4))
plt.plot(x, pdf)
plt.axvline(mean_target, linestyle="--", linewidth=1)
plt.text(
mean_target, pdf_max * 0.95,
"mean",
rotation=90,
verticalalignment="top",
horizontalalignment="right"
)
plt.title(f"Lognormal PDF\nmean = {mean_target}, sigma = {sigma:f}")
plt.xlabel("x")
plt.ylabel("density")
plt.ylim(0, pdf_max * 1.05)
plt.tight_layout()
frame_path = f"{tmp_dir}/frame_{i:02d}.png"
plt.savefig(frame_path, dpi=120)
plt.close()
frames.append(imageio.imread(frame_path))
os.makedirs("out", exist_ok=True)
gif_path = "out/lognormal-pdf.gif"
imageio.mimsave(gif_path, frames, duration=0.15)
```
%%
favorite-quotes.md
+23
View File
@@ -34,6 +34,29 @@ tags:
## About Process Optimization
### "It Takes an Engineer to Build a Bridge that Barely Stands"
> [!quote] Unknown
> Any idiot can build a bridge that stands.
> It takes an engineer to build a bridge that barely stands.
The phrase "exceeds specifications"
ought not be universally perceived as positive when divorced from context like it is.
It is often the case that exceeding minimum requirements is easy,
and that the difficulty (the kind that you pay people to handle)
is in meeting them precisely.
In the case of civil infrastructure,
it is intuitive that even though a 10% safety factor is _good_,
a 100% safety factor is not _better_.
It is _so_ intuitive that the choice of "_barely_ stands",
I don't think would give many pause or reservation.
However, divorced from context,
people are biased to believe that more of a good thing must be better,
especially when what's compromised isn't as tangible as dollars on an invoice.
### "Sharpen the Axe"
Frequently misattributed to Abraham Lincoln is some variation of:
lognormal-pdf.gif
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 133 KiB

music-theory-as-code.md
+9
View File
@@ -9,6 +9,15 @@ tags:
---
# Music Theory as Code
%%
## TALK
For now a scratchpad for implementation,
ultimately to discuss the difficulty
and why every extant library
seems to have wildly different ergonomics and terminology
%%
PowerShell module to assist in translating between banjo fingerings and concert notes,
as well as between [[lilypond]] and conventional notation.
music-theory-for-banjo.md
+7
View File
@@ -12,3 +12,10 @@ tags:
# Music Theory for Banjo
Cross-topic of [[music-theory]] and [[banjo]].
%%
## TALK
practical application of music theory concepts for playing banjo
including vocal accompaniment.
%%
nontraditional-computing.md
+22 -1
View File
@@ -10,4 +10,25 @@ tags:
---
# Nontraditional Computing
**Nontraditional computing** refers to UX patterns
**Nontraditional computing** refers to UX patterns
unlike those originally pioneered by Xerox and IBM,
and cemented by Apple and Microsoft.
Desktops, hierarchical filesystems,
obligatory mouse and keyboard
Perhaps more accurate is **nontraditional _business_ computing**,
since the real innovation is making mobile device patterns practical.
Designers frequently malign traditional computing,
stating accurately that it was a compromise
for restrictions that we no longer face,
but there is very little movement
on practical implementation of nontraditional patterns.
[Ink & Switch](https://www.inkandswitch.com/)
is at the forefront as I understand it,
however they have as much effort or more
invested in traditional systems.
[Liber Indigo](https://www.justinckirkwood.net/liber-indigo)
is mostly woo-woo, but has some fun things to say about NTC.
optimal-estimating-patterns.md
-37
View File
@@ -1,37 +0,0 @@
---
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
%%
risk-management-for-construction-estimating.md
+21 -5
View File
@@ -15,15 +15,31 @@ tags:
Cross-topic of [[risk-management]] and [[construction-estimating]].
## Estimating as Risk Mitigation
%%
## TALK
* reduce risk of wasted estimation effort due to bid loss
(prefer lower bid)
* reduce risk of project overrun
(prefer higher bid)
%%
## Bid Risk
**Bid risk** is not only risk of project overrun given award,
but also includes the risk of wasted estimation effort due to bid loss,
and the opportunity cost of excluding other opportunities.
## Estimating as Risk Mitigation
Estimating resources should be allocated
according to Return on Mitigation (RoM),
that is, their contribution to _cost certainty_.
$\text{Efficiency} = -1 \times \frac{d\sigma}{dt}$
But the RoM of estimating effort has a steep drop off,
and cost will obviously never be entirely certain.
It is not foolhardy to tolerate imprecision in an estimate
when the effort to increase precision
will not decrease bid risk at least equivalently
(stigmatizing "assumptions")
supertopics.md
+2
View File
@@ -18,6 +18,8 @@ They are a group of topics that,
while they may seem disparate in a vacuum,
are all fundamental to a greater understanding of the whole.
%%
## TALK
uncertainty-in-construction-estimating.md
-16
View File
@@ -51,19 +51,3 @@ Suppose the estimator is prescient and has observed the final cost of the projec
as reported in the winning contractor's historicals.
%%
## Expected Value of Perfect Information
[[uncertainty#Expected Value of Perfect Information]]
%%
an organization pays in estimator hours.
These hours have a direct cost in salary and benefits,
however the greater cost is the **opportunity cost**
of tying up an estimator who could otherwise be starting a new project.
In many cases, the [[utility]] of doubled throughput
far outweighs the increased risk of individual bids.
%%
utility-in-construction-estimating.md
+31
View File
@@ -0,0 +1,31 @@
---
id:
aliases: []
title:
tags:
- authorship/original
- destiny/permanent
- status/incomplete
- topic/estimating
- topic/risk
- type/cross-topic
---
# Utility in Construction Estimating
Cross-topic of [[utility]] and [[construction-estimating]].
## Expected Value of Perfect Information
[[uncertainty#Expected Value of Perfect Information]]
%%
an organization pays in estimator hours.
These hours have a direct cost in salary and benefits,
however the greater cost is the **opportunity cost**
of tying up an estimator who could otherwise be starting a new project.
In many cases, the [[utility]] of doubled throughput
far outweighs the increased risk of individual bids.
%%
utility.md
+4
View File
@@ -14,3 +14,7 @@ tags:
[Utility](https://en.wikipedia.org/wiki/Utility)
is a measure of a party's satisfaction
with a certain state of the world.
The measure is intended to account for unintuitive quirks of human perception of value.
A rich man is not as satisfied with receiving one dollar as a poor man,
therefore the utility of the dollar is contextual, not objective.