The excessive amount of NHibernate features  isn’t the only thing that is written down. There is also a good coverage of OO principles and Domain-Driven Design, although it isn’t the primary objective of the book of course. This is especially true for the first and the last three chapters. If you’ve already read the nominal books DDD and you are familiar with Persistence Ignorance, then you can safely skim through these chapters unless you want to see the interpretation of the authors when it comes to these principles. If you are new to these concepts, then these chapters are of great value to wet your appetite.

Although this book covers a lot of ground, I would certainly recommend it when you’re rather new to NHibernate and ORM’s in general. I guess this still includes me, although I’ve been using NHibernate for quite some time now. If you already have some experience with NHibernate, then this book probably doesn’t teach you that much. Still, it can quickly get you up to speed when you want to use a particular feature that you haven’t used before.

The only minor thing about this book is that I’m afraid that it will soon be out-of-date. The book only covers NHibernate 1.2.x and no features from the upcoming 2.0 release, which adds a lot of new and interesting features. It would be nice if the book already covered some of these features as most of them are ported from Hibernate itself, which is the original Java version.

On the other hand, this book provides an in-depth view of the basic features of NHibernate, which aren’t necessarily going to change that much over time anyway.

Let me round off this post by saying that I’m really impressed by the list of books that Manning is going to release the next couple of months. These are the ones that I’m particularly interested in:

• Building Domain Specific Languages in Boo
• ASP.NET MVC in Action
• Brownfield Application Development in .NET
• IronRuby in Action

I already bought LINQ in Action and also read a lot of good things about C# in Depth, which I’m going to pick up soon.

Take care.

What strikes me the most about this book is the fact that it has been published in 1999 (yes, almost an entire century in IT years). The content is far from outdated and could still be marked as innovative. I definitely know some co-workers and other people who could benefit a tremendous deal by reading this book.

The book is built around 46 short, self-containing sections with 70 different tips that will guide you to become a better programmer. The topics on orthogonality, reversibility, the DRY principle and the Law of Demeter really struck a nerve.

If you are serious about your profession, then you got to have this book and read it from cover to cover. There are only a few books that I want to reread at least once a year (PoEAA, DDD, etc. …). This book has now joined the club.

Elegant Code by Jan Van Ryswyck

What is elegant code? It might depend on who you ask. It’s kind of a subjective matter. Depending on the type of programmer, you get all kinds of answers. This short essay is my take on the subject. It’s a topic that is very close to my heart, although I believe I’m not able to produce very elegant code (yet).

In my view, elegant code has many characteristics. Here are some of these characteristics that I believe are important.

Elegant code adheres to object-oriented principles. We’ve all seen what a procedural approach does to a code base and its maintainability. Heck, there are even large tool vendors out there today that put out OO languages and preach software design that leans to typical Cobol. Good old plain classes: data and behavior that acts on that data. Code that reflects the Principles of Object Oriented Design, like the Single Responsibility Principle (SRP) and Separation of Concerns (SoC) to name two of them.

Elegant code reads like a best-selling novel. Remember that last book you’ve read that you just couldn’t stop reading? The same goes for elegant code. You start at the beginning of the code base and you can’t wait to see the rest. Code that invites other members of your team to read and review it. Code that does not have a need for comments, as it documents itself.

Elegant code is loosely coupled with a high cohesion. Orthogonal code is a very important topic. When you change one part of a system, it should not affect another part of that system. This can only be achieved through loosely coupled code. You gain productivity, reduce risk and increase maintainability.

Elegant code is therefore open to change and easy to extend whenever necessary. It should be very easy to make some fundamental changes to the code base, not only by its creators but by every other member of the team or even another team for that matter. This also involves some aspects like unit tests and continuous integration for example. These practices give any member of the team the ability to give immediate feedback about the condition of the code.

Elegant code clearly reflects the concepts of the domain for which it tries to solve problems and make life easier for its users. The model of the code should be understandable to both the developers as the domain experts.

Elegant code doesn’t try to reinvent the wheel. It is developed with the right tools for the right job without falling into the trap of the new technology du jour.

Last but certainly not least, elegant code does what it’s supposed to do. I’ve put this last, not because I think it’s not important. I believe that you automatically get working code when you apply every other characteristic I described earlier.

Notice that I mentioned the word team a lot. I’m a big believer of self-organizing teams that take matters into their own hands and pick up their responsibility. Elegant code is something that can be created as a team and most likely not as a sole individual. Although there are lots of very smart individuals out there, they are nothing compared to a team of open-minded, disciplined people who are set to meet their goal.

At the very real risk of getting myself blacklisted by the very famous rock star geeks named in this book, Dreaming in Code is anything but a success story. Indeed, the story of this software development effort provides great insight into why so many people hate computers, software, and programmers.

This is a real life story of the ineffectiveness of self driven work teams who can’t make a decision in the absence of an empowered leader. The team spends months deciding "architectural direction" before delivering anything, millions of dollars to deliver little to no value.

Dreaming in Code chronicles the team dynamics surrounding the group of people who built Chandler, Yet Another Outlook Killer application that, of course, did no such thing. The company established to create Chandler was founded by Mitchell Kapor, of the Open Source Application Foundation (OSAF) and original founder of Lotus Development Corp. Apparently this is what bored millionaires do with their fortunes in Silicon Valley rather than taking a vacation or feeding a village.

This team actually didn’t ship v1.0 for 3 years. They slid every schedule, they argued about the fundamental features of the system for months, they hard coded dependencies everywhere, and in short: They squandered money like only a group of self important, over-privileged , 21st century knowledge workers could.

Guess what? Life as a software developer (or as a user or customer) doesn’t have to be this way. Find a company lead by a visionary with the sense to hire a group of operators to execute on the vision. If everyone’s head is in the same cloud, none of them will keep their feet on the ground. Thankfully the team was beginning to use time boxed iterations with a set delivery timeline toward the end of the book. Who knows, maybe someday they’ll release v1.1.

I highly recommend this book. Dreaming in Code is the best anti-pattern for running a software team/project/company I have ever read.

Thanks to Cory, I have an extra copy of Beautiful Code, by Andy Oram and Greg Wilson. I already have a well worn copy of this excellent book, so this new one is up for grabs by our readers.

Here’s the Deal

You write an article for ElegantCode.com, and submit it to: contest at elegantcode dot com. The subject of your essay? If you have listened to the podcast, you won’t be surprised that the subject is "Defining Elegant Code". You tell us what Elegant Code means to you.

1. You send in your article by midnight on Friday, March 28th.
2. The Elegant Coders will read it and we will vote on a winner.
3. I will send you the book (shipping is on me).
4. We’ll post your article and attribute it to you as the winner of the contest.
5. You win fame and glory.

If you submit an article and are not chosen as the winner, we reserve the right to publish your entry in part or whole on the blog as well, but we will always ensure you are credited for your work.

Good luck, and we look forward to hearing from you.

I recently moved and in doing so I had to pack up all my books. Wow, there were a lot of boxes, currently well over 900 titles. Most of them have to do with Software engineering, programming, computer science, and business/leadership.

Some books I read just because the authors wrote them. Gerald Weinberg, Steve McConnell, Jeffrey Richter, Charles Petzold , Grady Booch, Bjarne Stroustrup, Johanna Rothman, Alfred Aho, and Cem Kaner are just a few of the many. Gerald Weinberg could write a book on dog washing and I would rush out an buy it. I know there would be wisdom inside on making great software.

I recently overheard someone ask a person knowledgable in a subject “Can you recommend any books on <insert technical subject>?” The person responded by saying, “No, I don’t really read books”. Wow, I thought. Please don’t tell me that Steve Jobs is right??? (http://digg.com/gadgets/People_don_t_read_books_says_Steve_Jobs). I have heard of strange people out there that don’t read books, but I always thought it was so beneficial to gain knowledge from those that have been there. Yes, there are lots of lousy books. But if you do a little homework, you can find the good ones.

During interviews, I’ll ask applicants how they learn. They inverably say “I look around on the internet”. Everyone says that. Lots of folks do get great information on the net. But I tend to think that is just the pat answer. I have found the wisdom to noise ratio on the internet to be extremly noise heavy. Sure, there are lots of gold nuggets of information. But you have to slog though a lot of black sand find them. I’ll also ask programmer and tester interviewees what books they have read in the last year. They usually mumble some fiction book. I just don’t get it…

So, what am I currently reading?

Working with Microsoft Visual Studio Team System, Hundhausen

Lessons Learned in Software Testing, Kaner et al

The Ruby Way, Fulton

Mastering Regular Expressions, Friedl

Whats next in the queue?

High Performance Web Sites: Essential Knowledge for Front-End Engineers , Souders

Essential ASP.NET 2.0, Onion

Execution: The Discipline of Getting Things Done, Bossidy et al

Programming Language Pragmatics, Scott

What are you reading?

Scott

In that spirit, here are some reading lists targeted to different people. I admit that a few of these books do not have a specific Agile focus, but are so fundamental to professionalism that they can’t be left out. If I have missed a gem, feel free to let me know. It may well be that I haven’t read it.

In the full sprit of disclosure, I have not read each of these books cover to cover. I have at least skimmed through each one in a concentrated sitting.

Developers

• Agile Software Development, Principles, Patterns, and Practices by Robert C. Martin
• Ship it! A Practical Guide to Successful Software Projects by Jared Richardson and Will Gwaltney
• Practices of an Agile Developer: Working in the Real World (Pragmatic Programmers) by Venkat Subramaniam and Andy Hunt
• Agile Software Development: The Cooperative Game (2nd Edition) (The Agile Software Development Series) by Alistair Cockburn
  or
  Agile Project Management: Creating Innovative Products (The Agile Software Development Series) by Jim Highsmith
• The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt and David Thomas
• Code Complete, Second Edition by Steve McConnell
• Extreme Programming Explained: Embrace Change (2nd Edition) (The XP Series) by Kent Beck and Cynthia Andres
• Integrating Agile Development in the Real World (Programming Series) (Programming Series) by Peter Schuh
• Pragmatic Unit Testing: in C# with NUnit
  or
  Pragmatic Unit Testing: in Java with JUnit

Testers

• Agile Software Development, Principles, Patterns, and Practices by Robert C. Martin
• Ship it! A Practical Guide to Successful Software Projects by Jared Richardson and Will Gwaltney
• Lessons Learned in Software Testing by Cem Kaner
• Practices of an Agile Developer: Working in the Real World (Pragmatic Programmers) by Venkat Subramaniam and Andy Hunt
• Agile Software Development: The Cooperative Game (2nd Edition) (The Agile Software Development Series) by Alistair Cockburn
  or
  Agile Project Management: Creating Innovative Products (The Agile Software Development Series) by Jim Highsmith
• Software Testing Fundamentals: Methods and Metrics by Marnie L. Hutcheson

Pragmatic Unit Testing: in C# with NUnit
or
Pragmatic Unit Testing: in Java with JUnit

Team Managers and Leads

• Agile Software Development, Principles, Patterns, and Practices by Robert C. Martin
• Agile Software Development: The Cooperative Game (2nd Edition) (The Agile Software Development Series) by Alistair Cockburn
  or
  Agile Project Management: Creating Innovative Products (The Agile Software Development Series) by Jim Highsmith
• Agile and Iterative Development: A Manager’s Guide by Craig Larman
• Ship it! A Practical Guide to Successful Software Projects by Jared Richardson and Will Gwaltney
• Agile Project Management with Scrum by Ken Schwaber
• Extreme Programming Explained: Embrace Change (2nd Edition) (The XP Series) by Kent Beck and Cynthia Andres
• Lean Software Development: An Agile Toolkit for Software Development Managers by Mary Poppendieck
• Managing Agile Projects by Kevin Aguanno
• Behind Closed Doors: Secrets of Great Management (Pragmatic Programmers) by Johanna Rothman and Esther Derby
• Agile Estimating and Planning (Robert C. Martin Series) by Mike Cohn

Project Managers

• Managing Agile Projects by Kevin Aguanno
• Agile Software Development: The Cooperative Game (2nd Edition) (The Agile Software Development Series) by Alistair Cockburn
  or
  Agile Project Management: Creating Innovative Products (The Agile Software Development Series) by Jim Highsmith
• Agile Project Management with Scrum by Ken Schwaber
  plus
  The Enterprise and Scrum by Ken Schwaber
• Agile Estimating and Planning (Robert C. Martin Series) by Mike Cohn
• User Stories Applied: For Agile Software Development (The Addison-Wesley Signature Series) by Mike Cohn
• Collaboration Explained: Facilitation Skills for Software Project Leaders (The Agile Software Development Series) by Jean Tabaka
• Agile Retrospectives: Making Good Teams Great by Esther Derby, Diana Larsen, and Ken Schwaber
• Manage It! Your Guide to Modern, Pragmatic Project Management by Johanna Rothman

Executives

• The Agile Enterprise: Reinventing your Organization for Success in an On-Demand World by Nirmal Pal and Daniel Pantaleo
• The Enterprise and Scrum by Ken Schwaber
• Accelerating Process Improvement Using Agile Techniques by Deb Jacobs
• Transparent IT: Building Blocks for an Agile Enterprise by Chip Wilson
• Implementing Lean Software Development: From Concept to Cash (The Addison-Wesley Signature Series) by Mary Poppendieck and Tom Poppendieck
• Managing Agile Projects by Kevin Aguanno

John has published these 10 laws that are not only worthy of reading, but worthy of groking all the way to your core.  Adherence to these principals is why companies like 37 Signals and Apple are getting so much good play.

John Maeda’s 10 Laws of Simplicity

1. Reduce
2. Organize
3. Time
4. Learn
5. Differences
6. Context
7. Emotion
8. Trust
9. Failure
10. The One