It seems there’s the dawn of a new term called Financial Risk Engineering.
I am beginning to be annoyed by this habit of appending engineering to fields,
that are too new to actually do any predictable engineering.
Ex: Software Engineering,Financial Engineering,Financial Risk Engineering etc…
Talk to me about Software Engineering, when the field has grown enough to
publish a 300 page Engineering data book with values for specific design cases.
Values, that have evolved as a result empirical experience and tinkering.
Otherwise, you are just tinkering or hacking.
I prefer tinkering since hacking has changed connotations in current usage.
I mean talk about safety factors and an idea of what safety factor,
to pick in what use-case,
and where exactly to apply/use them in the subsets of design case.
Only then, you can talk about Engineering. Otherwise,you’re just exaggerating,
for the sake of “i don’t know”(marketing/selling/cheating etc.)
Engineering at it’s core is about reliability,robustness under uncertain conditions.
To paraphrase, it’s about working around uncertainty(or entropy if you’re a mech.engineer).
The underlying point being, figuring out how to make things stable, even when there’s extra load.
It’s about designing a crane that doesn’t break and drop the steel girder,
because some worker placed a bucket of wet concrete on the girder and forgot to remove it.
If you can’t imagine, google for construction site accidents or
just ask your friendly neighbourhood construction worker for stories of injured friends.
But don’t fucking form opinions/judgements before any of these.
It’s about designing a CNC program, that doesn’t move the drill bit into the worker’s eye socket,
because the materials manufacturer, added extra carbon and the steel is harder than it should be.
Don’t append Engineering to a field, because that’s what you want to do.
Try to do it, try to create the data books etc..
And oh, by the way, I was just assuming design of one subpart of the machines in those previous cases.
Not to saying anything about reliability of the machine with all the parts together.
Last, I checked (admittedly atleast 10 years ago), that was still a greenhorn research field,
with not a lot of conclusive evidence/heuristics.
(Disclaimer: I don’t have any real life experience in the design,manufacture,use,feedback,re-design cycle for manufacturing.
The closest I have is writing software programs. Am a sellout in the eyes of quite a few people)
Ironically enough, the traditional fields, there seems to be a forgetting of these facts,
or atleast a movement/approach towards the let’s patch together stuff, sell it and then think about it.
Also, there was an interesting point that arose, while I was on an interview. Apparently mysql(even with innodb),
though provides ACID transactions for DML(CRUD On tables), DDL’s are not atomic.Damn, that’s painfully problematic.
That Oracle/mysql at PyCON 2012,Bangalore, conveniently omitted it when he was talking about mysql 5.5/6’s new features.
Caveat emptor indeed.
I bought a bicycle with gears, one which is the hybrid model, and the designers wanted a shock absorber.
So, they basically, added a Spring load to the core frame, the Spring is situated at the junction of the seat,
and the pedal frame. Now this means that all force I put on the pedal is also offset by my weight on the spring.
Overall, making me put extra effort on pedalling. Now one could say, just get a road bike.
True, but my point being, the designers did not bother testing the new frame design or it’s effects on pedal torque.
Welcome to the modern world where as Daniel H. Pink puts it “To sell is human” and therefore everyone should sell.
To be fair, his book doesn’t say everyone should sell, or one should compromise other stuff for selling,but does
observe the fact that in the modern world a lot of jobs involve some form of selling.
The problem being, the designer(s) of that bike model, would have an easier time selling, if they put up charts,
that project added revenues by presence of a shock-absorber or not, rather than trying to display revenue losses by increased pedal torque.
In this specific case, these revenue losses are by my recommendations (or lack thereof) and even negative reviews.
Moral of the story: via negativa proofs are harder to explain, harder tools to use to convince people to act*
(as compared to inductive/extrapolative projections under naive assumptions ).
Therefore, the simple act of trying to convince people can cause troubles in judgement of engineering quality.
So, if you want to get good Engg., try to keep the responsibility of selling Engineering decisions vs making Engg. decisions separate.
I am not sure about the best way to go about it, and am not qualified (in terms of experience or lack of it) to do that.
A heuristic I can think of is :
Make sure to ask what I am selling more often than who I am selling to.
P.S: if you found yourself agreeing eagerly with this rather meandering post, read this link.
* — I can speculate the reasons might lie in some cognitive biases, but that’s beside the point here.