Event-Based Programming: Taking Events to the Limit

APress was kind enough to send me a bundle of books for review. I've long been a fan of Apress b/c they always put out really high quality stuff and have more than their share of gems.  I definitely found one that qualifies as a real gem.

I definitely consider myself an early adopter on many technologies and I'm frequently guilty of liking stuff mainly because it's new and gives me  a chance to dig into something different.  Many times when I'm at client sites, I get asked about newer technologies that they are considering b/c I've gotten a chance to dig into their existing code base and can help make suggestions on whether or not something would be appropriate. 

Well, a few months ago, I was at a client site that was probably the most impressive client I've gotten to work with.  Their whole staff was smart, ambitious and they had really solid processes in place for just about everything.  I was talking with a lead developer over there about early adoption stuff and he made the comment "I think I'm going to lay off the new stuff for a while.  I'm going to go back over the old stuff and really make sure that I'm doing the existing things as best I can."  When I heard that, it really got me to reflect on some of my own habits and rethink how much effort I put into each different  basket.

With that in mind, I can tell you that Event-Based Programming is not at all a new cutting edge type of book, it's a 100% Pimp your game type of book.  In fact, I'd go so far as to say that there's a large segment of the developer community that might not like it.  Purely pragmatic developers that focus on just getting stuff done and eschew elegance as an unaffordable luxury probably will find this book a big long lesson on "I know I should do that but..." type material.    These folks often hate being bogged down with details and are a lot better at getting code done quickly than they are at writing bug free code that is easy to maintain.  Developers that mainly value maintainability in my experience tend to also be those who think that their code could always be better, that their designs could always be improved and really enjoy learning new ways to accomplish this goal.  If you fit into the second category, Event Based Programming is absolutely your book.  I know that the way I phrased this, it might sound like pragmatism and elegance are opposite ends of the spectrum and that folks that are get er done types won't like it.  That's not really the point I'd make. Rather, the real dichotomy seems to be between those that like doing all of the heavy work up front, or doing it later.  Because that's almost always the tradeoff.  There's merit to both approaches but I've seldom found people that really strike an even balance, people tend toward one end or the other. 

To that end, this book definitely has a computer science textbook aura to it. It's not a book you just read in passing.  It's thoughtful but demands that you think about each point the author makes and go on to think about the implications about it.  Yet none of it , at least as far as I can tell is ivory tower, sounds good in theory but not in practice material.  I can almost guarantee you if you read this book, you'll be struck but how much thought Ted Faison puts into every page. Having authored a few books myself, I couldn't help but be in awe of how he actually got this book written.  None of it was stuff you could just sit down and start typing out. 

It's an amazing book, unquestionably one of the best books I've come across in the whole time I've been working with .NET and excellent down to the most tiny details.

The first chapter sets the groundwork for the rest of the book. I'd say a good 90% of the books I come across, if not more, begin with a chapter that is largely just fluff. They are usually what we call a lot of yada yada and cover material that needs to be there for the uninitiated, but provide little value for folks familiar with the subject matter.  This book on the other hand, depends largely on Chapter 1.  It discusses the notion of Coupling and spends just under 70 pages introducing you to the concept in depth.  Inherently, coupling is neither good nor bad, it's just a reality of development. However how and why things are coupled matter greatly and when designing code, you have to live with the consequences of decisions you make, so he goes to great length to try to convince you why you should care about coupling.  The hardest part of reading this chapter was that it caused many flashbacks to things I've written over time.  It resonated loudly with me because he explains precisely what the consequences of making different decisions regarding coupling are, and it tracked identically with my own experience.  This chapter has a decent bit of code, a lot of UML and a lot of mathematical notation and proofs.  Back when I was studying CS, I really cared a lot about such material but often found I didn't really have time to engage in many things of this nature. However here, you can just open up any of your recent projects and apply what he talks about and examine the results.  Although it's heavy on theory, it's the type of stuff that I can almost guarantee you can be applied to whatever you are working on right now.

After he thoroughly introduces coupling, he moves on to Events and Delivery. This is a short and to the point chapter, less than half the size of the first one. In fact, it seems its main purpose is to transition to the next chapter on Notification Delivery.  The chapter on Notification delivery in turn transitions into the next chapter on Notification Payloads. 

This leads to a Survey of Commercial Systems.  This is a pretty meaty chapter that's mostly conceptual.  It's not  a chapter that teaches much in the way of coding, but serves well to reinforce the points he's made and continues to make. He follows this up by discussing Diagrams of Event-Based Systems.  Again, I'm not a huge fan of diagramming although I certainly appreciate it.  Too often I've fooled myself into believing I didn't have time to do it properly and it's clearly a shortcoming on my part.  If I had any doubt about this before reading the chapter, I walked away from it realizing how shortsighted I was being.  He continues this discussion with going into more detail by covering Signal Wiring diagrams.  Again, if you had any doubt of the value of correctly diagramming your systems, you won't after this. 

From there, he starts to cover the Mechanics of Event Firing. To be honest, I had to read this chapter a few times to really get it.  I understood it the first time, but it just struck me as something I couldn't learn too well.  Each time I read it, I walked away understanding something I had missed before.  From here, he moves on to a quick discussion of Event Based Interaction Patterns.  This was one of the easiest chapters to really understand b/c in large part, I think I knew a lot of the material if not by name. 

At this point, he introduces the concept of Functional Roles.  Again, this is  a heavy read. It's over 100 pages and it's all material that really does in fact belong in the same chapter.  I reread many parts of it and worked through the code examples just to make sure I really understood the nuances of each point, because there are many. It's not until this chapter that he starts getting heavy into code and I don't think you can truly walk away from the book without fully understanding this chapter and IMHO, working through the samples.  I don't profess to be particularly smart or gifted as a developer but I usually casually read through books and follow along without getting really up close and personal with each example. I did here. 

I think he realizes that it's not light material b/c he moves into a Case Study that is great.  It's great b/c it's pretty easy to follow along, is proximate to things we do regularly as developers and is thorough.  At this point, I can say that he really proves the importance of each point he's made prior to it.  When you get through this chapter, again, I can almost assure you that you'll feel as though you're development skills have evolved. 

So he takes it up a notch in the following chapter with another , slightly more involved case study and finished up the book with one last case study.  In each case, you'll invariably think back to the framework itself, and technologies that use it and say "So THAT's how they did it".

I don't blog about books unless I like them so it's nothing new for me to write a positive review.  However, this book had a much different effect on me than most do. In fact, as most people who I talk to regularly will attest, I feel in many ways like I've seen the light.  I already have a big mouth and I've had a hard time shutting up about the material in here.  There are just so many things that I've done wrong, or seen done wrong, that I knew was 'wrong' but really had trouble putting my finger on exactly why it was wrong. And IMHO , a big part of convincing people to adopt ideas you put forth is being able to put forth clear and easy to understand, yet compelling reasons to go along with you.  Just saying "It's bad programming practice" is seldom enough to convince people of much and often has the negative side effect of smacking people's egos.  Clearly articulating that something is so tightly coupled to other components that if any of your assumptions about the requirements are wrong or even slightly different that the ripple effects will cause major setbacks, and showing exactly where and why these weaknesses present themselves will get you a lot farther at making your point.

This book was written by a brilliant author who really put a lot of energy into it.  At every point of working through it I was continually struck by how much thought he put into each concept.  There's no fluff to it, none.  The examples are all non-trivial and get you thinking.  Fortunately, he uses examples and references that are very proximate that it's easy to stay engaged.  I don't think I  ever went off on a "when will I ever use this" tangent because as the point was  being made, I was thinking about where I've used or overlooked using the concept.  In fact, I'd have to say that's the hardest part of the book, staying focus, b/c to me, it was impossible to read through it without constantly thinking back to code I've written or am writing. And I literally went back to about 40% of the code of a project I'm currently working on and reworked much of it.  As cheesy as some of this sounds, I'd be willing to bet that if you read  it, you'll have a similar reaction to it.  I'd be shocked to hear anyone read it and tell me "I knew all of that" or "It was all theory, there wasn't much I could bring to the real world" because I know I couldn't even begin to make either claim.