Then about 2 months ago someone recommended Robert Greene’s The 48 Laws Of Power. If you’ve got certain goals in your life but are not quite sure how to achieve them, then i would certainly recommend it. Hell, i’d recommend it to anyone because it’s just that good and valuable. If i had read that book back when i was stuck in Enterprise Hell, i would’ve gotten through that period with a lot less friction and a lot more results. And for the record, that book isn’t necessarily about how you should use the power that you have, or how to put yourself in a position of power, but it’s a good guide on how to protect yourself against people who have power or are trying to gain power at your (or other people’s) expense.

That book lead me to The 50th Law which is a collaborative effort between Robert Greene and 50 Cent. Now, if you’re closed minded and don’t want to read a book that has a gangsta rapper associated with it, be my guest, but rest assured that you’re missing out on some very interesting and valuable stuff.

Next up on my reading list is The Prince and The Art Of War by Niccolò Machiavelli.

Now you might be wondering why i’m reading these kinds of books. Basically, because they really teach you a lot about how plenty of people think and react to things. That doesn’t mean that you have to follow the advice or the guidelines in those books, but it does certainly help you put certain things in perspective and understand certain situations better. And after all, if we are about self-improvement on a technical level, then we certainly should be open-minded enough to read books that could help us improve our understanding of other things in life as well. And i can guarantee you that the stuff you read in those books can help you in your professional life as well.

I’d definitely be interested in any other kind of non-technical, non-fictional book that you can recommend for whatever reasons

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.

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.

• 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.

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.

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.

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.

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.

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.

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?

This book is a must-read for anyone doing any kind of management (even if it’s just project management), and i’d even recommend it to non-managers as well. It is just filled with great insight, tips and things that everyone should know about, not just managers.

And for those of you who’re too lazy to read a book (and i know there’s at least a few of you ), it’s only 160 pages so it’s not like this will eat up a lot of your time.

The book is divided in 3 parts. The first discusses the mechanics of making changes in code. The second part consists of very conveniently titled chapters that discuss common problems when changing legacy code. Chapters with titles like “I don’t have much time and i have to change it“, “How do I add a feature“, “I need to make a change, what methods should I test?“, “Dependencies on libraries are killing me“, etc… You can quickly look at the table of contents and find the right chapter to help you with the problem you’re facing at that time. The third part of the book contains a series of dependency breaking techniques that are referenced throughout the book.

If you are working on a legacy code base, do yourself a favor and get this book. Put it next to your keyboard, and use it everyday. You won’t regret it.

At around 350 pages (depending on which of the appendices you find useful), this book really covers a lot of ground, but in a concise (without being _too_ concise) way. You’ll find the typical sound advice on using good names, writing good functions, good vs bad comments, formatting, abstractions, encapsulation, robustness, integrating third-party code, testing, refactoring, class design, system design, enabling emergent design and dealing with concurrency. After all of that, there are a couple of chapters where existing code is improved step by step. To top it all off, the final chapter contains an extensive list of smells and heuristics.

Some of you are probably thinking that all of this looks rather familiar, especially if you’ve read books like Code Complete, Refactoring and Implementation Patterns. And this book really doesn’t offer anything new that nobody ever wrote about before. It is however the best, and most accessible collection of good advice on good code and design that i’ve read so far.

Well, perhaps cheap isn’t the best word to use. After all, some of these books are somewhat expensive, and buying a lot of them certainly adds up. But if you pick the right books, they are usually more than worth the money they cost. Besides, you shouldn’t just look at the price of the book. The most important thing to keep in mind is the knowledge and insight you can get from them. That typically depends on the type of books you buy though. I usually avoid books that are library/framework/language-specific, unless i am very interested in a specific topic.

The books that usually provide the biggest value are the ones that teach you things that you can use in any development environment. It can be about development methodologies, certain concepts or practices, patterns (not just design patterns but architectural patterns, coding patterns, testing patterns, …), as long as the knowledge is reusable. These kinds of books allow you to learn from the experiences of some of the best people in this industry. And the best thing about it is that you can learn a lot from these books in a few days (or weeks), even though it probably took the authors a couple of years to acquire that knowledge and experience. Isn’t that one of the coolest forms of reuse you can think of?

Now obviously, reading a couple of books won’t instantly put you on the same level as the authors, but at the very least it allows you to significantly increase your skills and insight with relatively little effort. And when you start applying that knowledge, you can start reaping the benefits of it pretty soon. It could definitely make your job easier. It most likely will increase the quality of your output at work. It almost certainly increases your value as a software developer.

So do yourself (and everyone else) a favor, and read a good book on software development once in a while. And if you need some help picking out the good books, just look here

But simply grouping them as ‘Must Read’ and ‘Highly Recommended’ was not such a good idea, so now i’ve grouped them in the following categories:

• Writing Code / Working With Code
• Software architecture/design
• Language/Technology specific
• Software development approaches/practices/methodologies

Chech out the list and buy those books! The money you spend on them will be earned back continuously through the raises you’ll eventually get after properly using their knowledge