Inspiration for MVVM Unleashed
There are a number of timeless books that you’ll hear mentioned in technology circles. They are respected as treasure troves of information for the software craftsman looking to hone his skill. I have a confession to make. While I have referenced these books and discussed their ideas in conversations. Many of them I hadn’t taken time to read. There are a few that I had read cover to cover e.g. Gang of Four Design Patterns, Fowler’s Patterns of Enterprise Application Architecture (which I referenced heavily in my MSDN Article). And some that I had read enough to get a good understanding (Eric Evans Domain Driven Design). And still others that I flat out hadn’t read. Like Clean Code; Refactoring to Patterns; The Pragmatic Programmer; and Uncle Bob’s Principles, Patterns, and Practices. I took two weeks off at the end of 2010 and downloaded the last four to my Kindle (well I bought the physical edition of triple P because it’s not available on Kindle in either the Java or C# edition).
I started by reading the intros to all of the books and their first chapters. Then I honed in on Clean Code and Refactoring to Patterns since I feel that they harmonize well with the approach I’m taking with my book. I’ve finished Clean Code fully and am a quarter of the way through Refactoring to Patterns (taking copious notes using Kindle’s markup feature). I was pleasantly surprised to find that I had already internalized a lot of the ideas discussed in Clean Code. It was nevertheless enlightening because it made some of the lessons that I had learned more explicit.
My interest in Refactoring to Patterns came from my inference of what the book would be about from it’s title. It looks like Kerievsky followed the principle of least surprise in naming his book because right off the bat, he said exactly what I had been thinking and planning for MVVM Unleashed:
If you’d like to become a better software designer, studying the evolution of great software designs will be more valuable than studying the great designs themselves. For it is in the evolution that the real wisdom lies. The structures that result from the evolution can help you, but without knowing why they were evolved into a design, you’re more likely to misapply them or over-engineer with them on your next project.
Of course I highlighted that passage and made a comment about it. I’ve seen MVVM misused very tragically misused. I’ve seen countless cases of people saying that they don’t see the big benefit of MVVM. I’ve encountered misunderstandings of just what MVVM is and what it isn’t. The goal of my book is to impart the knowledge of MVVM, the associated patterns, and its benefits by helping my readers “discover” MVVM for themselves. It’s a lofty goal, but in my eyes it’s attainable. Of course I could just be swinging my sword at a windmill but time will tell.