Where was this conversation done? 1 inch = 2.54cm so 10 inches is 25.4cm. I could get people rounding upwards to 26cm, but how you get to 27cm is a mystery to me

The "no one is trustworthy" philosophy has been debunked e.g. the research of Zimbardo (Stanford Prison Experiment), Sherif (Robbers Cave Experiment) en Milgram (the shock experiments) have all been proven to be hoaxes based on a lot of manipulation. People naturally trend to organize themselves with a lot of solidarity. JJ.Rousseau's view is pretty close to reality as it turns out. It's not a plea for condition-less immigration, but the idea that no one is trustworthy is plainly not true.

The science on what to eat exists, it is just barely spread by the public sector as their guidelines get influenced/watered down by politics and most businesses benefit from not telling it. I strongly recommend Dr Greger's books: how not to die, how not to diet and his website http://nutritionfacts.org./ Next to telling you what not to eat (highly processed foods, meat, saturated fats, dairy products ...), the daily dozen is an approach to what to eat: https://nutritionfacts.org/app...

(sorry now without messed up formatting)

You need to teach senior managers what the nature of IT projects is, and manage their expectations. Assuming you mean ERP (enterprise resource planning) and not ERM (enterprise risk mgt):

• manage stakeholder expectations. If there is momentum to do such project, it's usually because everybody is emotional: we need to do something, we need to act now! You need to render this much more objective, so everybody is still on the same plate one year down the road: clear objectives, how success will be measured ...
• (as suggested before) clarify why this momentum is there, each stakeholder has her reasons. Formalize these.
• these projects tend to cost 3-10 times the license cost of the package: integration, change management
• it takes senior mgt commitment: adopt the package, don't adapt the package (customizations are difficult to maintain in the long run: loss of internal knowledge, package upgrades ...). But adopting the package means changing the way things are done today.
• define the top 15 (or so) processes for the company, and based on these select the best-fit package, then be rigorous on minimizing customizations afterwards (again senior mgt commitment)

Expect a bumpy ride.

You need to teach senior managers what the nature of IT projects is, and manage their expectations. Assuming you mean ERP (enterprise resource planning) and not ERM (enterprise risk mgt): * manage stakeholder expectations. If there is momentum to do such project, it's usually because everybody is emotional: we need to do something, we need to act now! You need to render this much more objective, so everybody is still on the same plate one year down the road: clear objectives, how success will be measured ... * (as suggested before) clarify why this momentum is there, each stakeholder has her reasons. Formalize these. * these projects tend to cost 3-10 times the license cost of the package: integration, change management * it takes senior mgt commitment: adopt the package, don't adapt the package (customizations are difficult to maintain in the long run: loss of internal knowledge, package upgrades ...). But adopting the package means changing the way things are done today. * define the top 15 (or so) processes for the company, and based on these select the best-fit package, then be rigorous on minimizing customizations afterwards (again senior mgt commitment) Expect a bumpy ride.

I don't agree with most of the recommendations above. Mixing semantics as happens in a lot of modern programming languages is not good for learning: pointer vs. copy passing as in primitive types vs. objects etc. Floating point vs. integer arithmetic with its automatic conversions ... When learning to program, there are 2 totally different things to learn: 1. clearly structuring a problem 2. the nitty gritty messy stuff: pointers, floating point number issues (rounding), communication with hardware (I/O), A language like Pascal (if you have a dialect with supports pointer dereferencing (original pascal only made this possible via var-parameter passing) forces one to structure the problem, has very strict semantics and still lets one learn the complexity of pointers and the essential data structures: trees, lists ... Complement it with structured programming and stepwise refinement (Dijkstra) to learn to structure problems. Once one masters all this, it becomes a piece of cake to write a well-structured C program, and picking up on all the additional nitty gritty stuff that C doesn't hide. With ADT (abstract data type) based programming in Pascal, one approaches OO programming, and the step to OO-pascal or C++ can then be made. A great language for learning how to structure a problem is a functional language like Haskell. Strongly typed, lazy evaluation, support for unlimited lists etc. Based on lambda-calculus, hence with strict semantics. Sorry, but have no book recommendations at hand.