Code Obsession

This book, available for free download on InfoQ.com, is an excellent intro to/summary of Evans' DDD book. What I really appreciate about this book is that at 104 pages it is short enough I can recommend it even to my near-illiterate developer friends who would never attempt to tackle Evans' 560 pages. ;-) The definitions of the key terms in Domain Modeling are clear and concise. The examples are short and simple which forces them to cut straight to the heart of the concept they demonstrate. While this book doesn't go as deep as Evans' book, it is excellent as a review or intro. I intend to have my entire team read through it asap during our ongoing training. Key to Domain-Driven Design is the concept of the Ubiquitous Language. This book helps define the terms used in the Ubiquitous Language of software development. Communication is the key to success in our industry and having a common language facilitates quick, clear communication between developers. Read the ...

Robert Glass' Facts and Fallacies of Software Engineering was an interesting read because it focuses so much on the research that has been done in our field. Contrast that with the much more common anecdotal teaching style and this book becomes very valuable for the industry. Honestly, most of the facts are well known, they just may not be accepted as facts. This is a quick read and worthwhile. The emphasis on research and evidence alone is worthwhile.

I recently read Pete McBreen's Software Craftsmanship: The New Imperative. This was a pretty interesting book and it was excellent timing because I finished it just before Dan North published his post that set off an avalanche of debate about the topic. What can I say... Hmm. After all the debate, I still consider myself to be a craftsman. Why? That is an interesting question. I think that there is misunderstanding about the movement. I think craftsmanship is all about building maintainable software and training the next generation of programmers to build maintainable software. As a professional, ROI is king. Everything I do, from personal study to TDD to CI to leading group discussions about the craft is so that my team can produce better, more maintainable software that produces long term business value. This is what makes me a craftsman. I have seen too many projects lose focus and become unmaintainable piles of crap. I have seen too many failed rewrites. I have se...

When I started the blog, I thought I would share a lot of my experiences and thoughts about software development. After all, I am code obsessed. I read and think about code almost as much as I actually code. What I have learned about myself is that I don't really have much desire to write about what I read and think about. The reason for this is simple: I feel it is all derivative. What I mean by that is that any serious developer has read read Clean Code, Pragmatic Programmer, Refactor, Refactoring to Pattern, Patterns of Enterprise Application Architecture, Agile Software Development, Service Oriented Architecture, SOA in Practice, Domain Driven Design, Applying Domain-Driven Design and Patterns, Head First Design Patterns, Facts and Fallacies of Software Engineering, Pro ASP.NET MVC Framework, Practices of an Agile Developer, the 97 Things books, etc, etc. He/she also probably follows blogs like Los Techies, DotNetKicks, Object Mentor, InfoQ, Joel on Software, Martin Fowler...

I've been using a ServiceLocator class for IoC for the last year and a half. Never really got the point of the containers until the last week. We had a strange API requirement for a component for another group. I didn't agree with it, but basically, they wouldn't let us do constructor or setter injection of the dependencies. Let's not get into that, but lets just say that grabbing StructureMap 2.5 and throwing it into the mix saved me a ton of time. Also, I now get it. The container took what would have been 30-50 lines of ServiceLocator.cs and made it less than a dozen. And they were very clean and easy to read. And since you can initialize the objectfactory where ever you need to, I was still able to test those blocks and get a high level of coverage. I have been using RhinoMocks since I first started TDD and I am pretty fond of it. The AutoMocker in StuctureMap has forced me to shift from the using(mocks.Record()){}... style to the Arrange-Act-Assert style. ...

So after realizing that the 10,000 page book on ASP.NET is better as a reference than as a training guide (seems like someone said that several times before we started this book), we voted on whether to read Clean Code or Refactoring to Patterns next. Considering the make up of our team and the state of our code, I lobbied fairly hard to get Clean Code in front of everyone before we dive into patterns (again). It seems that a lot of our more experienced developers are pretty resistant to reading Clean Code. I think there is a mentality that "the way I do it is right and there is no need to change or improve." I think that is pretty sad. I read Clean Code a few months ago, and it has helped me vastly. It is amazing how much more maintainable my code is now. Anyway, I think that for my team (we have not quite a 3 to 1 ratio of juniors to seniors) we need to have a purpose to our refactoring. Making our code more readable and reducing our coupling seems like a pretty worth...

So it turns out that I prefer writing code to writing about code, but I just finished reading Uncle Bob's "Clean Code: A Handbook of Agile Software Craftsmanship." I highly recommend it. This book very clearly addresses the large majority of the issues I face every day at work. Our environment is full of code that works, but was never finished. In other words, the code is a mess. I'm passing the book around work hoping that it will help spread the vision. Hopefully, we pick it up as one of our next training books for the whole team.