Great question. Once I read Robert C. Martin's book Agile Principles, Patterns, and Practices in C#, I just felt the desire to teach them at work.
My manager supported me and allowed me to take the whole team (about 10 developers at the time) out of work for an hour a week, and present to them all.
Here are the lessons I learned from this:
Strictly after 60 mins, they begin to loose interest, unless you can keep them interactive the whole way through. Now, I always felt even 60 mins was perhaps not enough time to explain each principle from an academic point of view and then mainly a "Real-World" perspective.
What I found to be absolutely effective, was taking the current companies code, and showing them a problematic area, and a before and after the principle was applied. It was even more effective, when people had burning issues with a product, that they couldn't solve. So I took those problems and resolved them with SOLID, and showed the process of how I achieved that.
One lesson per week was plenty for them to think about. I usually would have days of discussions of that one principle right up until the next week and beyond. It was quite pushing for time also trying to get the presentation prepared, finding some code that wasn't going to step on peoples toes if I showed it up on a projector etc. Bear that in mind - use your own code if you can, or at least get the developers permission, and better yet, teach him before the presentation and let him present the solution with you - this worked great also!
I threw in the Clean Code principles in there too, then progressed on to SOLID, then branched in to testing and TDD. I have the course I prepared for the whole thing. I don't mind sharing that if you drop me a message :).
Oh, and everyone hates the Liskov Substitution Principle. Was hard for me to dig out an example of this in the company software.
I found the more academic the presentation was, for example, this is a class Shape, this is a class Circle that derives from Shape, etc, the more boring it was for them. I would throw in a very quick academic example after explaining the principle, then focus mainly on a real world problem that they can relate to.
If you don't fancy the thought of class room presenting, maybe you can just do the digging out of some of the companies code, a before and after, and a document attached explaining why it is you changed it in such a way, to conform to SOLID. People can then read it and study it in their own time. I did this post presentations and some people found that more useful. They were also uploaded to a company Wiki.
So happy to see more people willing to teach SOLID off their own back. Well done :).
