**Review of yesterday**  
As developers, we have promoted a view of the world that is really tech-centric.  This has caused recruiters to look for tech-centric skills _only_ and ignore developers that have spent 20 years in insurance, but know the business perfectly.   **Exercise**  
How to convince for change back at work

- No appeals to authority (Udi said do this!).  Usually ends up with other appealing to other authorities and you don't get anywhere.
- No attacks on particular technologies (web api sucks!).  This just ends with hurt feelings (the guy who just finished a web api project).
- There is a LOT of business reason to stay with the way things are!  It's hard to convince a business stakeholder to up-end current practices and fix problems with new technologies when fixes can just as well be put into place with known technologies and by expanding what we're already doing.
- Keep in mind: to convince, we need to prove we've thought through the pros and cons of the messaging pattern approach and thought about the impacts on reliability, scalability, performance, etc and still need to go this route.
- Udi doesn't recommend using messaging on a brand new product, out of the gate.
- When making significant change to how a system works (implement messaging as a small replacement to a piece of the system), leave the old way in place and have a configurable value that switches between the two.  This is a safety net for the stakeholder/decision maker to go back to the old way if anything goes wrong.
 EasyNetQ ( [https://github.com/EasyNetQ/EasyNetQ](https://github.com/EasyNetQ/EasyNetQ)) - nice little library for basic messaging on top of RabbitMQ.