“It would be well if engineering were less generally thought of, and even defined, as the art of constructing. In a certain important sense it is rather the art of not constructing; or, to define it rudely but not inaptly, it is the art of doing that well with one dollar, which any bungler can do with two after a fashion.” Arthur Wellington
Where is the boundary between finance and engineering? And Engineering is also about making optimal tradeoffs in other dimensions (he mentions time, performance, scalability, sustainability, and efficiency).
In reality, it's more like: any idiot can build a bridge that, in some places, is 5X as strong as it will ever need to be, in other places 2X as strong, and in a couple places only 0.8X as strong as it will ever need to be.
It takes the engineer to build it so that every part is 1.25X as strong as it will ever need to be, consistently everywhere.
To the idiot, that then looks like it is barely standing, because some parts are 4X weaker than he would have made them, based on bad intutition.
In modern days we generally stand in awe of ancient structures that have stood for millennia.
But in some sense, many ancient engineers had to drastically overbuild their bridges and other structures because they didn't have the tools to know what the "barely stands" threshold was, so they had to build for a big margin of error when they lacked the tools of precision.
Most of those old bridges are not suitable for modern needs. They are nice to look at, but cannot carry a truck, or can only at very low speeds. Or buildings without restrooms. Just adding light to old things often destroys the beauty people praise them for
Yeah, imagine digging up red clay, throwing it in a charcoal furnace, and then hammering it for a while. You can tell you're getting wrought iron, but would you know from one batch to the next whether it's good?
> The stresses in the dome were found to be substantially reduced by the use of successively less dense aggregate stones, such as small pots or pieces of pumice, in higher layers of the dome. Mark and Hutchison estimated that, if normal weight concrete had been used throughout, the stresses in the arch would have been some 80% greater. Hidden chambers engineered within the rotunda form a sophisticated structural system.[55] This reduced the weight of the roof, as did the oculus eliminating the apex.
That said, I'm guessing the Pantheon is in one piece (unlike the coliseum) because it's been used as a church for the past ~1600 years and presumably (similar to Notre Dame) it gets repair as-needed.
On the other hand, in many cases what's defined as the "bare minimum" ends up being more than expected. The corner-cutting approach ends up pricier than the thorough approach in the long run, because it must be constantly adjusted if not entirely re-done.
e.g. building a bridge to support a city's normal traffic density, but the city ends up growing, and the way the bridge was designed makes adding reinforcement difficult. Or building a bridge whose materials start to melt at a certain temperature that's above what's expected for the region, but climate change raises the temperature over the threshold, so it needs a completely different material.
Hence the article's point that software companies should invest in formal methods, because while formally proving something is a long process without much reward in the short term, it eliminates an entire class of bugs which, in some long-term projects, makes it worth the effort.
Conversely, we also know that taking longer to build something scalable is more expensive than just building cheaper things that accomplish the job now and solving the bigger problems when they’re relevant to the point where it can be the tipping point of success in the first place. In other words, that super reliable bridge that can handle all the growth you throw at it can take longer and too much money and result in a city that fails to have a growth problem in the first place.
We know that’s true experientially in both CS (YAGNI) and in the physical spaces (eg Wright brothers constantly iterating with cheap prototypes until they figured out something that worked and SpaceX doing similar things with their prototypes). Iteration = learning. In theory formal methods let you iterate at a cheaper phase of the project. In practice, the methods themselves are very difficult to scale to large projects and these days require you to build the project twice - once for the formal language and then hand-translated to a production language.
Even with an unlimited budget and unlimited time, the difference between good and bad engineering is that a bad engineer won't know where to apply their talents to ensure things won't go wrong in the future. While every discipline in the world is bound by budget and time constraints (even an armchair philosopher has a limited lifespan), that doesn't change the essence of the discipline itself.
I think of engineering not just as designing and building things, but also knowing where the limitations are of the thing you're constructing, whether it's purely on paper, in a computer's memory, or from brick and mortar.
For me, engineering is applied science for money. That's the main thing.
Someone is paying for everything you do.
We get into it because we care about the how more than the why, but we end up having to deal with the who is paying for this.
The boundary is fuzzy, engineering is heavily influenced by finance, otherwise it's just a hobby.
Formal methods are great or an awful decision depending on wether or not they make economic sense for your product or service at your organization's current stage.
Amazon EC2? A large, mature org, with products with extremely high fubar potential? Go wild.
Your startup where market-fit is not proven? WTF? Are you high? use that money on something else.
It's like unit testing, it in general makes great sense if the cost of maintaining the tests is lower than the opportunity cost of slowing down. If you're prototyping something that you'll likely throw away, it may be a bad idea. Once it proves value, you better build a decent test harness.
Startups take technical debt because it's cheap when the market fit is not demonstrated (you pay it back later once you have succeeded somewhat).
It's a rational decision.
You don't need perfection if you're building the wrong thing, first you figure out if what you're building makes sense, then you decide in what to invest.
On the other hand, if you're building a deep space probe, a large scale distributed system for hire, or any other thing were a failure is BAD (with capital letters), the extra cost of ensuring correctness is well worth it.
> The boundary is fuzzy, engineering is heavily influenced by finance, otherwise it's just a hobby.
This rings true for me. I'm interested in learning things, e.g. how processes work in Windows NT kernel, or how to write a custom memory allocator, instead of creating a product. I do have some passion for a certain product but it is highly personal and won't be shared.
Quoting David Cutler, "What I really wanted to do was work on computers, not apply them to problems". I wish I knew this when I was younger.
I feel like money is too narrow here, but there does need to be some kind of budget involved. For instance, getting the energy output of a nuclear fusion reactor to exceed the energy input is an engineering problem. An energy budget, in that case.
Absolutely it is about trade offs, sometimes bugs are just an inconvenience and time-to-market is more important. But bugs can result in lost business and even lost lives, for example UK Post Office Horizon. Horizon was built (bungled) on the cheap, but the overall cost of that saving must be dwarfed by the financial cost of the resultant scandal.
Depends on whether the systems you're working on have catastrophic failure modes, or not. In terms of how the responsible parties behave in both realms, it comes down to whether the costs of catastrophic failure can be externalized or not (e.g. government bailouts for chaos in in subprime mortgages or natural gas futures markets, Price-Anderson indemnity for nuclear reactor meltdowns). Miscalculation (see Boeing) can be disastrous.
Now if you can't externalize the costs of catastrophic failure, that will be the fundamental constraint on your engineering / finance strategy. If you really don't want your network to be breached, you'll build it around security features, not try to hack them on after the fact. I like to think SpaceX, as a private company without the kind of political heavyweight backers that ULA enjoyed, thus put a lot more effort into avoiding the kind of problems ULA is currently having, for just that reason.
Conclusion: take away the government safety nets, and both engineering and finance will perform better? Now about Silicon Valley Bank...
