Other reviewers are predictable in when they say 'this is not C# or agile' what they are really saying is 'I do not want to learn OO design'.

Agile teams must have OO design mastery or they tend to iterate to release 1 with legacy code. After that it is a disaster to change or make long-lived.

If you actually believe that agile lets you neglect OO design expertise that myth is put to bed here.

Are you a .NET C# developer who (forget agile) doesn'r really understand 'favor composition over specialization/inheritance'? Then read this.


You can work in software with a lot of gaps, but the content here defines what is mandatory for even moderate levels of team based success, and this is not my opinion this is proven fact over 10 years of our industry evolving.

Do you agree in the following as a common value of `good' for software?

FROM: http://articles.techrepublic.com.com/5100-10878_11-1050347.html

Good design

Well-designed applications offer software components that are more robust, more maintainable, and more reusable. Such applications should be able to adapt changing business needs without affecting design. For example, a banking application should be able to support new types of accounts without a change in the existing design.

Three key points of good design are:

Maintainability, which is the ease with which a software system or component can be modified to adapt to changing environments, improve performance, correct faults, or other attributes. Well-designed applications require fewer resources for maintenance and changes.

Reusability, which is the degree to which a software module or components can be used in more than one computing program or software system. Reusability of software components helps ensure faster development of software applications.

Robustness, which is the stability of software applications in extreme situations (e.g., maximum load conditions, erroneous user inputs). Robust applications have less downtime and can reduce maintenance costs.

Bad design
Nobody plans to create ill-designed applications. It often happens because of a lack of experience or because the app was designed quickly to meet an extremely tight deadline. Poorly designed applications usually have these problems in common:

They're rigid. A design is rigid if it cannot be easily changed. For example, a single change to heavily interdependent, rigid software could begin a cascade of changes in dependent packages. When such a program grows in size, the designers or maintainers cannot predict the extent of that cascade of change, and the impact of the change cannot be estimated. This makes the cost of the change impossible to estimate.
They're fragile. Poorly created programs have a tendency to break in many places when a single change is made. Simple changes to one part of the application can lead to failures in other parts that appear to be completely unrelated. Fixing those problems leads to even more issues, and the maintenance process begins to resemble a dog chasing its tail. Such fragility greatly decreases the credibility of the design and maintenance organization, which leaves users and managers unable to predict the future quality of the product.


They're not reusable. A design is difficult to reuse when its desirable parts are highly dependent upon other details, which aren't desired. If the design is highly interdependent, other designers will also be daunted by the amount of work necessary to separate the desirable portion of the design from the parts that aren't reusable. In most such cases, the cost of the separation is deemed to be higher than the cost of redevelopment of the design.

Still with me? Ok..


.NET developers historically have lacked (as compared to other OFA (one framework only) developers) at the very, very least) acceptable OO Design skills. I mean even remotely `predictably' acceptable. Sure I worked with many teams who were exceptions but they were all from other (Java/Smalltalk) environments. Even C++ developers can slant to a master of C, deep internals, and Fragile Base Class disaster (grin). So Microsoft would have been nuts as they have always know this to put multiple-inheritance into C#. I digress... This is relevant to the book I swear....

Uncle Bob Martin created a masterpiece here that is still just as (more?) relevant. It is utterly transformative for anyone who wants to be even remotely productive on a team of best-practice types.

FYI this is the book used when I teach 'Core Object Oriented Design for the C# Developer' around the country.

NOTE: Do not let the word 'Agile' fool you. This is a book about best practices in software design and development. Agile just assumes you already know this material, yet most I work with do not.

He provides definitive coverage of the most critical reasons for failure if you skip then. For example, inheritance in OO is wrong for most cases used today in .NET.

Liskov substitution principle
Read this (covered in detail in this book):


Kind Regards,
Damon Wilder Carr
http://blog.domaindotnet.com

Reader,

This is a book about far important topics than Agile (and Agile is darn important).

It is far more valuable than any other book today on Agile for the development trenches to read.

If you hate the word Agile (you likely either have incorrect ideas what it means or only the buzzword exposure) this book still will fix youor showstopping lack of knowledge if applicable (and if your not sure, you do not have it, I promise).

You can work in software with a lot of gaps, but the content here defines what is mandatory for even moderate levels of interesting work.

Do you agree in the following as a common value of `good' for software?

FROM: http://articles.techrepublic.com.com/5100-10878_11-1050347.html

Good design

Well-designed applications offer software components that are more robust, more maintainable, and more reusable. Such applications should be able to adapt changing business needs without affecting design. For example, a banking application should be able to support new types of accounts without a change in the existing design.

Three key points of good design are:

Maintainability, which is the ease with which a software system or component can be modified to adapt to changing environments, improve performance, correct faults, or other attributes. Well-designed applications require fewer resources for maintenance and changes.

Reusability, which is the degree to which a software module or components can be used in more than one computing program or software system. Reusability of software components helps ensure faster development of software applications.

Robustness, which is the stability of software applications in extreme situations (e.g., maximum load conditions, erroneous user inputs). Robust applications have less downtime and can reduce maintenance costs.

Bad design
Nobody plans to create ill-designed applications. It often happens because of a lack of experience or because the app was designed quickly to meet an extremely tight deadline. Poorly designed applications usually have these problems in common:

They're rigid. A design is rigid if it cannot be easily changed. For example, a single change to heavily interdependent, rigid software could begin a cascade of changes in dependent packages. When such a program grows in size, the designers or maintainers cannot predict the extent of that cascade of change, and the impact of the change cannot be estimated. This makes the cost of the change impossible to estimate.
They're fragile. Poorly created programs have a tendency to break in many places when a single change is made. Simple changes to one part of the application can lead to failures in other parts that appear to be completely unrelated. Fixing those problems leads to even more issues, and the maintenance process begins to resemble a dog chasing its tail. Such fragility greatly decreases the credibility of the design and maintenance organization, which leaves users and managers unable to predict the future quality of the product.


They're not reusable. A design is difficult to reuse when its desirable parts are highly dependent upon other details, which aren't desired. If the design is highly interdependent, other designers will also be daunted by the amount of work necessary to separate the desirable portion of the design from the parts that aren't reusable. In most such cases, the cost of the separation is deemed to be higher than the cost of redevelopment of the design.

Still with me? Ok..


.NET developers historically have lacked (as compared to other OFA (one framework only) developers) at the very, very least) acceptable OO Design skills. I mean even remotely `predictably' acceptable. Sure I worked with many teams who were exceptions but they were all from other (Java/Smalltalk) environments. Even C++ developers can slant to a master of C, deep internals, and Fragile Base Class disaster (grin). So Microsoft would have been nuts as they have always know this to put multiple-inheritance into C#. I digress... This is relevant to the book I swear....

Uncle Bob Martin created a masterpiece here that is still just as (more?) relevant. It is utterly transformative for anyone who wants to be even remotely productive on a team of best-practice types.

FYI this is the book used when I teach 'Core Object Oriented Design for the C# Developer' around the country.

NOTE: Do not let the word 'Agile' fool you. This is a book about best practices in software design and development. Agile just assumes you already know this material, yet most I work with do not.

He provides definitive coverage of the most critical reasons for failure if you skip then. For example, inheritance in OO is wrong for most cases used today in .NET.

Liskov substitution principle
Read this (covered in detail in this book):


Kind Regards,
Damon Wilder Carr
http://blog.domaindotnet.com

I have read Bob's books/articles over the last few years. He has a way of explaining a solution that I have never experienced in any other books. This book is not an exception to that. I enjoyed reading everypart of this book. Must read for a C# developers.

Agile practices and design patterns written in a clear, concise way. Granted there are a handful of mistakes throughout the book, and the occasional awkward reference to a pattern that won't be covered for another 5 chapters, but they're easy to spot.

The information is presented just right - a little background info, succinct descriptions, and simplified code examples. Outstanding.

Very readable, entertaining, useful. One of the few books that has been easy to follow and enjoyable to read. Very good general coverage.

I have purchased and read alot of books on software design and development over the years and I cannot think of a single one of them that I would rate higher than this one.

Simply the best treatment of object oriented design, patterns and practices I have ever read. Extremely well organized and easy to read. Should be in every software engineer's library.

First, this book is well written and presents information in a constructive manner. It is well thought out, and is not just another C#/OOP/XP book.

Now for the bad news. One unnecessary oversight is the use of casts and "object" in some examples. Any author writing any C# book since 2005 must know that these idioms should no longer be encouraged. It is unacceptable for a book published in February 2007 to possess this flaw.

Generics, used in moderation, result in cleaner code that is also type-safe, and usually performs better due to the absence of boxing/unboxing. The authors should consider posting alternative examples that favor Generic types and collections on their errata web page. If you purchase this book, you would be well-advised to review the examples with a bias against the use of casts and the word "object".

To be entirely frank, I don't see how other reviewers can justify a five star rating.

This book teaches both OOP and agile methods. The two are independent! The authors provide a brief introduction to UML as well. Some prior knowledge of fundamental OOP concepts such as inheritance and polymorphism are assumed. This is not a critical analysis of Agile or OOP. The book does not explain how agile methods can scale. That may be deficiency of agile methods. The book is blunt about Use Case Diagrams: useless (pardon the pun); with which I cannot agree more.
Except for one twenty-person project I worked on, I would advocate Agile for all the smaller projects I have done in recent years. I would highly recommend the book for all C# developers. Java developers would be better of with the previous Java version of the book.

This book is amazingly great from start to finish. All the basics of good agile development are covered clearly and sensibly in the first section: what agile is, how to go about it, why testing and planning are so critical, and where refactoring fits in all of this. Design and general patters are hit in the second section, again in a clear, concise, and sensible fashion -- and with common sense thrown in.

The final two sections cover a real-world case study implementation of a payroll system. Here the rubber meets the asphalt: walking through use cases, building transactions based on smartly-chosen patterns, discussion of what patterns make sense where and why, implementation, packaging, and evolution.

I found myself shaking my head in wonder as I read this book and stumbled across one nugget of gold after another. Some bits of goodness pop out in the middle of nowhere simply because the authors are so well-versed in their domain that they're letting fly wisdom even when discussing other topics. An example of this is in the XP pairing session episode where some discussion of increment operator side effects is tossed in the middle of another discussion stream. You read that section once and pass over it, only to do a head check, bounce back and re-read it while nodding your head and saying "Yeah, that's absolutely right and I might not have caught that otherwise."

Another bit of greatness is the chapter on UML. The authors are emphatic about keeping UML tightly in check and using it only in specific cases where it makes clear sense. Mountains of UML diagrams are not the answer; the authors show where a few concise diagrams make perfect sense.

More goodness can be found throughout the book in the gems relating to any number of design issues such as a small example of a problem the authors put forth to students of their various design/patterns courses: build a coffee maker. The authors go through the most common result they see and show the specific problem areas of that solution -- and then show a solution that is amazing in its simplicity, elegance, and maintainability.

This book is a critical read for folks at any level of experience. I'm going to do my best to make sure it gets on the required reading list for developers at my company.

Robert Martin is one of the smartest people I've ever talked with, and he is one of the best technical writers I've ever read.

This book is *the* most comprehensive and most valuable introduction and guide to Agile programming, with a full discussion of Agile principles, the "fourteen practices of eXtreme programming," full discussion of "spiking, splitting, velocity, iteration, test-driven development, refactoring, pair programming, five types of UML diagrams," and how to use all of this in real world .NET development.

There is no doubt in my mind that this book will make you a better programmer, will challenge you, will teach you, will take you beyond what you already know, and will entertain you along the way. Robert is as good as it gets.

This book is required reading. Do not hesitate.

Advanced developers will benefit from a book which packs in case studies to illustrate C# development and design routines, and will also appreciate the smooth move from UML models to C# code, which flow between initial logic and explanation to actual applications and upward migrations of skills levels. C# as well as Visual Basic or Java programmers will find the progressive, technical lessons and applications an important key to understanding the foundations of agile software principles and shared strengths.

Diane C. Donovan
California Bookwatch

This book really covers two topics: Agile management methods and development practices used by agile team.

Section I, the description of the Agile methology is brief. This is obviously the intent of the author and agile is meant to be documenation-light. This section only consists of 100 pages. It's a quick read giving you everything you need to know to implement the Agile methodology in your team.

Section II, is titled "Agile Design". These chapters are high-level design principles with low-level examples and a thorough treatment of UML. This should have been split into two sections. This first, would be most useful for a beginner/intermediate developer to take their skills to the next level. The second part, is required reading/knowledge for any developer who needs to work with a team or who needs to plan a complex application.

Section III is presented as a case study. Under the guise of a desiging a payroll system, the authors present the most popular design patterns. This section depends on the previous sections and is a great example of the thought process of agile developers.

The book is well written and easy to read for intermediate to advanced developers. Beginning developers would stuggle with some sections. However, all levels would beneift from reading this book.

Based on the (only) other 3 reviews on this site, I decided to read this book. However, like I mentioned above, the book is one giant Linked List - let me explain: In every chapter, they introduce a hitherto unexplained topic and ask you to leap forward 10 chapters to learn more about it - for eg:

From Chapter 9 - OCP: "Figure 9-1 shows a simple design that does not conform to OCP. [...] Figure 9-2 shows the corresponding design that conforms to the OCP by using the STRATEGY pattern (see Chapter 22)."

The whole book is filled with stuff like this. Another example: Right from Chapter 1 the book starts using UML - however the intro chapters on UML are laid out in Chapters 13-19. Totally beats me.

And there is nothing C-Sharpy (C#) about this book. There are some miniscule snippets which have been converted to C#. Nothing in the book leverages the unique features of the language - It is as though a lexical analyzer took the old book, converted the Java snippets into C# and auto-published it.

I have spent over 6 hours with this book now and am at chapter 10 - and I dont feel that I have learnt anything significant of value - the same ol' XP, Agile story and a very shoddy treatment of patterns.

Nothing differentiates this book from the hordes of others out there. I think Accelerated C# 2005 by Trey Nash would be a much better alternative - atleast, in there, the authors don't snub the .NET programmers out there like in here:

Quoting from the preface:
"Teaching week-long courses on various software topics allows me to meet a wide cross-section of developers from around the world. Many of the students I've instructed were .NET programmers, and many were Java or C++ programmers. There's no gentle way to put this: In my experience, .NET programmers are often weaker than Java and C++ programmers. Obviously, this is not always the case. However, after observing it over and over in my classes, I can come to no other conclusion: .NET programmers tend to be weaker in agile software practices, design patterns, design principles, and so on. Often in my classes, the .NET programmers had never heard of these fundamental concepts."

I was willing to put up with all the opinionated commentry as long as the content was good - but now, I see no reason to have to eat their uncooked dogfood and be disrespected while doing so.

Anyone want this (almost brand-new) book for half price? :)

In one sense, the book covers no new ground. The Agile principles and patterns discussed here have been well explained for two other languages, Java and C++, especially by Robert Martin in an earlier book.

What is offered here is a recasting in terms of C#. Which however has far fewer practitioners than the other languages. Some sections of the book are mostly independent of any language. Take the chapter on state diagrams for documenting finite state machines as one example. Or the other chapters on object diagrams, use cases, sequence diagrams and class diagrams. Some of these do have example code in C#. But inherently, they tend to stand above any language.

Some principles are quite useful, albeit perhaps to an advanced programmer. A good example is the chapter on Interface Segregation Principle. Basically, it's about how an interface can grow, if there are several child classes that implement it. The problem is when some classes need routines added to the interface, that other classes do not. So we get a fat interface. This creates a cross-coupling that is unneeded, and a potential source of errors. Something that you should try to minimise, for long term robustness and ease of code maintenance.

As the other reviewer mentioned, this book is unique in its breadth. It does an excellent job of combining the development process with actual patterns and practices of development.

It gives a fairly thorough examination of each topic in a surprisingly small amount of words. It seems as though the authors have applied the principles of agility to their writing style. They do not overcomplicate things. They give you only the information that is required to cover the subject.

Overall, I agree with the writer of the forward. In General, .NET programmers are not as strong as other programmers. And this needs to change. This book can help that happen.

This book is unique in that it covers software principles, metrics, patterns, packaging, design smells, UML, and agile programming practices all in one book.

It uses great real world examples, and has a ton of code with them. They are all explained very thoroughly.

What I like the most is he includes the mistakes usually made in real world environments and then works his way back onto the right path.

I read the Java version from cover to cover, although I do no Java. The contents are just to important to live without. Now that it is out in C# I am re-reading it from cover to cover.

If you develop using an OO language, you must read this book.