I’m not the best debugger out there, but i usually manage to get to the bottom of things and sometimes i even enjoy chasing down a weird bug.  And while i actively try to avoid bugs as much as possible, i’m also always looking to learn more techniques or practices to efficiently find and fix bugs when they do occur.  So when i first heard about Paul Butcher’s Debug It, i immediately preordered it.  And now that i’ve read it, i’m very glad i did.

The book is divided in 3 parts.  The chapters of the first part explain in depth what kind of debugging strategy you’ll need.  Discussed topics include:

• figuring out what you’re really looking for
• tips and tricks to come up with a reliable reproduction of the bug and the value of having that reproduction
• diagnosing the actual problem
• coming up with a true fix
• reflecting on why the bug ever got into the software
• making sure that the bug can’t come back and that we learn from the mistake

For some of you, most of this stuff will just be common sense.  For a lot of developers though, this part alone should be considered required reading.  It’s a complete process of how to deal with bugs efficiently in less than 80 pages!  Think about that for a second: 80 pages that will improve your efficiency at your job and will reduce the amount of time you spend doing something you probably don’t like doing.  How could you resist?

The second part is pretty short (only 2 chapters) but pretty interesting as well.  It mostly deals with organizational patterns and practices that a development shop should take into account.  It covers things such as:

• the importance of bug tracking
• what makes a good bug report
• effective communication with users and support staff
• giving priority to bugs as soon as they’re discovered
• the importance of pragmatic zero-tolerance for bugs
• ways to get out of a Quality Hole

Not all developers will like the second part, but it definitely contains some valuable information for technical managers, or for developers who need to convince their technical managers

The third part of the book deals with a lot of various strategies for a variety of specific situations.  While not everyone will get something out of every topic discussed in this part, odds are that quite a few of them will indeed be interesting for you.  You’ll find specific advice for quite a few special cases (performance, concurrency, backwards compatibility, third-party bugs, etc…).  You’ll also find the obligatory chapter on creating an ideal debugging environment with automated tests, a build system and continuous integration.  If you’re reading this blog, you’re hopefully already convinced of the values of such things so you might want to skip this chapter.  The final 2 chapters are again very interesting… They’ll show you how you can write software that will debug itself.  While not everyone will actually go out and do this, some ideas of that chapter should definitely be kept in mind by most of us.  The final chapter deals with some common (mostly organizational) anti-patterns for dealing with bugs.

All in all, there is just a lot of tremendously valuable information in this book.  And it’s only about 190 pages so it definitely won’t take you a long time to read it.  I’ve frequently been amazed at the inability of developers to efficiently debug issues when they occur.  And i’m not just talking about bad developers.  I’ve seen plenty of good or even great developers having trouble with debugging efficiently.  This book would definitely get them on the right track, with just a little bit effort.

As i mentioned in my (short) review of ‘97 Things Every Software Architect Should Know’, i love the format of these “97 Things” books. I already pre-ordered the upcoming ‘97 Things Every Programmer Should Know’ and was curious about the other book in the series: 97 Things Every Project Manager Should Know.

Now, i’m not a project manager and have no intentions of becoming one in the future. But as a software developer, i do think it’s important to have an understanding of what good (and bad) project management entails so i’d recommend this book to project managers as well as developers. As usual with books in this series, it’s full of useful, real-world advice and common sense contributed by experienced and established project managers. Each piece of advice is again only 2 small pages, and no topic is ever discussed too in-depth. While not everyone will get something out of every bit of advice, there surely will be quite a few that’ll make you think about improvements that can be made in your company.

While there is no structure in the order of the tips, the book does list each tip by topic in the beginning. Topics that are covered are agile methods, general software development, managing people and teams, dealing with distributed teams, improving communication, managing stakeholders, project processes, dealing with requirements, dealing with end-users and self-management. The book claims to be useful to project managers in general and not just for software projects, though i think non-software project managers will probably not get a lot of valuable information out of this book since the large majority of the tips are rather specific to software development.

Definitely worth reading.

I’ve developed this bad habit of reading about a book (usually in blog posts), thinking “hmm, that should be interesting”, going to Amazon, ordering it and then forgetting all about it. The whole process takes less than 2 minutes. I have recently bought the following books, all of which i still have to finish:

• 97 Things Every Project Manager Should Know: i love the 97 Things series, and i think it’s important to figure out how project managers think (just as it’s important for men to figure out how women think) so i had to pick this one up. I am about halfway through at the moment.
• Debug It!: Too many developers have trouble figuring out where to look when something goes wrong. I’m proud not to be a part of that group (on most days), though i keep my eyes and ears open for any kind of debugging tips so i just had to pick this one up.
• Growing Object-Oriented Sofware, Guided By Tests: i never knew about this book, but i happened to glance over it in a list of recommended books based on another book that i was buying at the time. Once i spotted the “Kent Beck Signature Book”-series logo i clicked the “Add to shopping cart” button. That’s right, i’m that big of a Kent Beck fanboy.
• Advanced .NET Debugging: This is the book i got suckered into buying today… why? because Tess Ferrandez recommended it. Yup, i’m that easy. Seriously though, how could it be bad?
• Writing Secure Code: 2nd Edition: I started reading this about 2 months ago. I’m currently at page 154. It’s that boring.
• Enterprise Integration Patterns: As cool as i suspect this book to be, i still haven’t made it past the first chapter. Which i started about 3 months ago. It’s not that it’s boring, i actually think that messaging is very cool… but for some reason i can’t get myself to read this thoroughly when there are other things to do that are more relevant to what i need at work.

The subtitle of Ship It is “A Practical Guide To Successful Software Projects”, which it most certainly is. While it doesn’t cover nearly as much ground as The Art Of Agile Development, it does contain enough valuable information that will improve the way you attempt to deliver working software.

That is, unless you’re already doing things like Continuous Integration, automated testing and code reviews. While these topics certainly aren’t the only practices that are discussed in the book, they are pretty much the practices ‘building blocks’ that this book depends on. If you’re already using these practices in your projects, then odds are that you won’t really learn anything new from this book. However, if you’re not doing this, or your projects are just a mess and you really have problems delivering software, then this book will definitely help you to improve your situation.

The book first covers a couple of tools and the necessary infrastructure that you’ll need to successfully develop software. Things that some of us will take for granted (source control, CI server, change notification, issue tracker, etc…) but that not everyone is using (apparently). After that, some solid practices are covered, such as the importance of having a technical lead and the responsibilities that come with this job, communication and coordination between all team members, and extensive code review practices (this part was especially good IMO).

The book then also covers ‘Tracer Bullet Development’ which is an approach that the authors recommend for all projects. It basically comes down to using a layered architecture that is loosely coupled and nicely encapsulated along with some good advice in general on how to get working functionality into your system quickly, yet sustainable. Finally, the book closes with (usually) solid advice for a list of typical problems that many teams are suffering from.

Again, if you’re already using the practices that i mentioned in this review then you most likely will not really benefit from this book, and you’d be better off reading the Art Of Agile Development instead to improve what you’re already doing. But if you’re not using any of these practices yet, this book should help you improve your working environment very quickly and rather easily.

As far as Object Relational Mapping (ORM) in the .NET world goes, NHibernate is one of the more mature, powerful and popular options available. But learning how to use it properly can take some time. NHibernate In Action aims to lower that learning curve significantly.

The first 2 chapters offer a general introduction to ORM, some reasons why NHibernate is the authors’ preferred ORM, and a step-by-step guide to creating your first NHibernate application. Topics such as NHibernate’s (high-level) architecture and configuration are also covered here.

The book then proceeds to cover some important NHibernate concepts in depth. First up, writing and mapping classes. This particular chapter doesn’t cover really advanced mapping scenarios (a later chapter takes care of that), but it does cover most of your options very thoroughly. This isn’t just basic mapping though. You’ll already learn about various types of associations you can have and the three available strategies for inheritance mapping.

Once you’ve learned how you can map your objects, you can start working with them, which is what chapter 4 covers. You’ll learn about the persistence lifecycle, working with transient/persistent/detached objects, dealing with object identity depending on the current state of your objects, transitive persistence (cascading options), and you are introduced to some of the possibilities for object retrieval.

Chapter 5 teaches you how to deal with transactions, the various options to deal with concurrency and it also covers NHibernate’s caching features very thoroughly. All 3 of those topics should be very clear to you after this chapter

After that, the authors revisit the subject of object mapping again in Chapter 6, this time covering some more advanced options. The stuff you’ll learn about in this chapter is very interesting, but in most cases you won’t need these features. But it’s good to know that they are there in case you need to handle more exotic mapping situations

Chapter 7 is probably one of the most important chapters of the book, as it deals with various ways and methods to retrieve objects efficiently. You’ll get great coverage of HQL in this chapter, and you’d be surprised how powerful it is. In most cases, you’ll see the equivalent of the HQL statements using the Criteria API of NHibernate, but (and this is one the few gripes i have with this book) for some of the advanced concepts (namely projections and grouping) they completely ignore the Criteria API and focus solely on HQL. I’m a pretty big fan of the Criteria API so i obviously find that a little bit disappointing. It does cover pretty much everything else you want to know about querying with NHibernate though.

The final 3 chapters deal with using NHibernate in the real world. These chapters might be of use to people with little experience in (proper) software development, but i don’t really think most people will really get a lot of value out of these last 3 chapters. Topics covered here: layered architecture, common design goals you should aim to achieve, some options with regard to generating code/mappings/database, dealing with legacy database structures and more. Again, this might be interesting to some, but definitely not to all.

Overall, i would say that everyone working with NHibernate would benefit greatly from reading this book. If you’re just getting started with NHibernate, it will indeed lower your learning curve significantly. If you already have experience with NHibernate, you will most likely learn some tricks that you didn’t know about yet. It’s a good book to read cover to cover, but at the same time it will be of great service to you as a reference book. Chapter 3 through 7 especially are chapters you’ll probably revisit frequently while you are working with NHibernate.

There is one thing to keep in mind though… this book targets version 1.2 of NHibernate, which is a bit of an old release. This is rather unfortunate since NHibernate 2.0 and 2.1 introduced a lot of great new features. Obviously, these great new features aren’t covered here, but the most important things of working with NHibernate are all covered thoroughly so don’t let the 1.2 version number make you think that this book isn’t relevant to the current versions. This book is by far the best source of information on how to get the most out of NHibernate.

97 Things Every Software Architect Should Know isn’t really a book… it’s pretty much a collection of bits of wisdom and advice from a bunch of leading software architects. There are no chapters, there is no unifying theme, there is no structure whatsoever. There is just a lot of great content. Around 50 software architects contributed 97 pieces to the book, each one filling up about 2 (small) pages. In a way, reading these pieces feels like reading great blog posts, though without the usual blogodrama. It’s great stuff for when you want to spend an hour reading, or for when you have a couple of minutes to spare. There’s even a website which contains all of the original, unedited contributions so the cheapskates among you can read it all as well

As i mentioned recently, i’m taking advantage of the low value of the British Pound by ordering quite a few books through amazon.co.uk. I’ve recently ordered even more books, so i now have the following books lying around, waiting to be read:

1. 97 Things Every Software Architect Should Know: this is one is pretty cool so far… lot’s of great, short tips which makes it ideal to read while you’re taking a dump (Borrower Beware!)
2. NHibernate In Action: This looks like it will be the definitive resource for using NHibernate properly.
3. Data-Driven Services With Silverlight 2: gotta increase that Silverlight knowledge.
4. Framework Design Guidelines, Second Edition: this one was also on the previous list
5. Ship It: this one was also on the previous list
6. Enterprise Integration Patterns: this one was also on the previous list
7. Writing Secure Code: this one was also on the previous list

I plan to read them in that order (unless you can convince to me change the order)

I also have a copy of Refactoring To Patterns lying around, which i borrowed from work… no idea when i’ll actually get to it though.

I recently started working on a Silverlight project, and since i had no Silverlight experience at all, i ordered a copy of Chad Campbell and John Stockton’s Silverlight 2 In Action so i could quickly brush up on the subject. This book is a great resource for those who are new to Silverlight, as the authors gradually build up your understanding of Silverlight’s features and capabilities.

While it probably doesn’t cover everything there is to know about Silverlight, it definitely covers most of the things you’ll be dealing with when developing with Silverlight. However, it doesn’t really teach you how to build real-world applications with it. There is very little focus on application architecture, so if you’re already familiar with Silverlight and want to learn how to properly build your applications with it, then this book is probably not for you. But if you are new to Silveright or have little experience with it, then i would definitely recommend it to get to know what Silverlight can do for you, and for what you can do with Silverlight.

I always figured writing a Domain Specific Language (DSL) would be such a dauntingly complex task that the chances of me being able to pull it off would be slim to none. With that in mind, i was pretty interested in reading Ayende Rahien’s Building Domain Specific Languages in Boo to find out just how difficult it would be.

In the first chapter of the book, Ayende mentions his success criteria for the book:

I hope that by the end of this book, you’ll feel that you are able to tackle problems in your
domains and solve them by building Domain Specific Languages to solve those problems in
an elegant manner.

Quite a goal, and i was very interested to see if he would be able to pull it off. Let’s hold off with answering that question for now, and let’s go over the content of the book.

In the first chapter, Ayende basically brings you up to speed on the different kinds of DSL that you can create, covering pro’s and con’s of each approach. Most importantly, he provides some answers as to why you would want to create your own DSL and discusses why he chooses to create DSL’s on top of the Boo language.

Chapter 2 gives a brief overview of the Boo language. I didn’t know Boo yet, so this chapter was very useful and interesting for me. You learn some basics of the language, and you’ll also find out why it’s such a good candidate to build your DSL on top off. The only downside about this chapter is that i had to refrain myself from running off to go play around with Boo. Boo seems very interesting and extremely powerful, and it definitely deserves more exposure within the .NET world.

In the next 2 chapters, Ayende walks us through the implementation of a couple of DSLs (each has a different purpose), while continuously offering a lot of great advice and discussing many of the different decisions you can make while you’re building your DSL, including how you can integrate your DSL with your actual business domain API. This is very nicely done, in a manner that makes you feel like you’re sitting right there with him as he is considering each possible direction to take. After these 2 chapters, you already have a pretty good idea of what exactly is possible to do in your very own language. We’re also introduced to Ayende’s open source Rhino DSL project, which already does some of the heavy lifting of actually making your DSL executable.

Chapter 5 deals with how you can actually integrate your DSL into your application. A DSL can be very nice, but if it doesn’t integrate nicely with your application, it’s pretty useless isn’t it? That’s what this chapter is for. Topics like storing of the DSL scripts, order of execution, performance implications, security considerations, dealing with errors and administration of scripts in general are all covered pretty nicely here.

Up until this point, most of the stuff in this book has been pretty easy to grasp. Chapter 6 however might occasionally leave your head spinning. This is where we get into making sure the compiler behaves the way we want it to. Think about that. As developers, we’re used to making sure that we comply with what the compiler expects from us. Now we actually get to turn this around. This chapter is by far the most difficult one in the book, but it is definitely important that you take the time to understand everything this chapter covers. It’s basically about extending the capabilities of your language (instructing the Boo compiler on how to compile your DSL, introducing new keywords, or even modifying the behavior of existing language keywords) to provide the best possible experience for the consumers of your DSL. Again, some parts might leave your head spinning. Read them again and again until you get them because it’s not only very important to understand, it really is fascinating stuff.

The next chapter deals with the infrastructure you need to support your DSL, based on Rhino DSL. You don’t need to use Rhino DSL, but it certainly makes a lot of the tasks involved easier to handle.

In chapter 8, Ayende covers the importance of testing your DSL, and how you can do it. It not only covers how to create a testable DSL, it also shows you can extend the xUnit.NET testing framework to make it easier to write unit tests for your DSL scripts.

By now, you already know a lot about how to build a high quality DSL and how to integrate it with your application. But there is more to it than just creating a fancy DSL and making it work. You need to make sure that the DSL is maintainable in the long term, and that it is easily accessible and comprehensible for the intended users of the language. The next 3 chapters deal with all of this. Topics covered are multiple versioning strategies, properly documenting your DSL, and even creating a professional UI on top of your DSL. A UI for a DSL you ask? Well, depending on the intended users, you might want to create a nice GUI on top of it, or you might want to create a bit of an IDE experience (complete with syntax highlighting and code completion). All of these possibilities are also covered nicely in this book. After that, Ayende covers a bunch of typical DSL implementation patterns that you’ll probably find very useful when creating your own DSL.

For those of you who are familiar with Ayende’s blog, you’ll be happy to know that the writing style is very similar. It’s very engaging, it keeps you interested in the topic at hand throughout the book, and he often makes you marble at his ability to come up with simple and elegant solutions to difficult problems. I used to be skeptical towards the actual value of creating your own DSL, but now i know that it is not only doable, there really are a lot of cases where it makes sense to create a DSL, more than i’d ever imagined.

I think Ayende achieved his goal. I do think that i can now create a DSL, and i’m sure many of you would agree with me after reading this book. In most cases, it’s pretty easy with this book by your side. And for those cases where it gets hard, this book thoroughly covers all of your options. Do yourself a favor and read this book, you won’t only learn a lot about DSL’s, but also about problem solving in general.

What does any self-respecting European development geek do when the British Pound’s value is so low? That’s right, he orders some books from amazon.co.uk to take advantage

I now have the following books lying around here, all waiting to be read:

• Framework Design Guidelines, Second Edition
• Silverlight 2 In Action (yes that’s right… Silverlight… the ‘cool kids’ might not like it, but it really is an interesting platform that’s only going to get better and better in the next couple of years)
• Enterprise Integration Patterns (i’ve been getting more and more intrigued with messaging so i figured it was time to spend some time learning more about this)
• Writing Secure Code (i know waaaaay too little about writing secure code so this was also something i’ve wanted to study for a while now)
• Ship It!

I can’t wait to read each one of them, but the book i’m currently reading is Ayende’s Building Domain Specific Languages In Boo. I’ve only read the first 4 chapters so far, but it has already been fascinating.

How about you? Which books do you plan/hope to read in the near future?