Your Lordship, Ladies, Gents and dear members of the Forum, anyone recommends this book?

The core ideas are good but I personally find it a bit too "artistic" for my taste. Probably half to 2/3 you just skip/skim over quickly. While the 1/3 where the real material is, you will need more than 1 careful reading plus extra thinking/coding.

Jim Coplien is one of the founders of the patterns movement and developer. Later he got into process (more 'artictic' as MM notes) patterns.Coplien was using C++ as a multi-paradigm language when the rest of us were creating (deep) class hierarchies.I have not read the book but I expect it has lots of 'experience stories' that you can only learn by doing it yourself. I am sure it has good stuff in it.Does the book discuss Scrum??? Don't like that stuff.

From Dr. Coplien himself:"If any buzzwords loom even larger than Agile on the Agile landscape itself, they are Scrum and XP. We figured that we'd lose credibility with you ifwe didn't say something wise about them. And maybe those of you who are practicing Scrum confuse Lean with Scrum or, worse, confuse Agilewith Scrum. Scrum is a great synthesis of the ideas of Lean and Agile, but it is both more and less than either alone. Perhaps some clarification is inorder. This section is our contribution to those needs. This book is about a Lean approach to architecture, and about using that approach to support the Agile principles. Our inspirations for Lean come through many paths, including Scrum, but all of them trace back to basics of the Lean philosophies that emerged in Japanese industry over the past century (Liker 2004): just-in-time, people and teamwork, continuous improvement, reduction of waste, and continuous built-in quality. We drive deeper than the techno-pop culture use of the term Lean that focuses on the technique alone, but we show the path to the kind of human engagement that could, and should, excite and drive your team. When we said that this book would build on a Lean approach to architecture to support Agile principles, most of you would have thought that by Agile we meant "fast" or maybe "flexible." Agile is a buzzword that has taken on a life of its own. Admittedly, even speed and flexibility reflect a bit of its core meaning. However, in this book we mean the word in the broader sense of the Agile Manifesto (Beck et al 2001). Speed and flexibility may be results of Agile, but that's not what it is. The common laws behind every principle of the Manifesto are self-organization and feedback. Scrum is an Agile framework for the management side of development. Its focus is to optimize return on investment by always producing the most important things first. It reduces rework through short cycles and improved human communication between stakeholders, using self-organization to eliminate wait states. Scrum encourages a balance of power in development roles that supports the developers with the business information they need to get their job done while working to remove impediments that block their progress. This is not a Scrum book, and you probably don't need Scrum to make sense of the material in this book or to apply all or part of this book to your project. Because the techniques in this book derive from the Agile values, and because Scrum practices share many of the same foundations, the two complement each other well. In theory, Scrum is agnostic with respect to the kind of business that uses it, and pretends to know nothing about software development. However, most interest in Scrum today comes from software development organizations. This book captures key practices such as software architecture and requirements-driven testing that are crucial to the success of software Scrum projects (Coplien and Sutherland 2009)."and finally, something we do agree upon Dr. Cuch: "Don´t like SCRUM either".

Deepak Chopra is more useful

QuoteOriginally posted by: CuchulainnDoes the book discuss Scrum??? Don't like that stuff.if you say this out loud on a job interview - you're a toast

It depends on who are you interviewing with. You might get lucky, who knows. Good IT managers are very accomodating and agnostic regarding "methodology", as long as you know your stuff...

QuoteOriginally posted by: quantmehQuoteOriginally posted by: CuchulainnDoes the book discuss Scrum??? Don't like that stuff.if you say this out loud on a job interview - you're a toastThanks for the tip; I'll remember that. QuoteGood IT managers are very accomodating and agnostic regarding "methodologyIndeed. edit: Scrum idea does have a social aspect in that it gets people talking. But where it fails imo is when it pretends to / replace design experience.If you build a house, you don't want the scrum team scrumming arount the coffee machine every morning deciding what to do next. The architecture should drive the project. If you don't have an architectural vision, then oh boy watch out.In one sense, s/w design has a long way to catch up on h/w or even engineering design.

QuoteOriginally posted by: CuchulainnIf you build a house, you don't want the scrum team scrumming arount the coffee machine every morning deciding what to do next. the scrum (meeting) itself is a good idea: daily stand-up 15 minutes discussion of issues. the problem's with Scrum as a methodology, which is not just one meeting in the morning. it's a tip of the iceberg, there's a lot of other ridiculous things in Scrum

Exactly, I have seen scrum teams betting on sprint stories with fibbonnacci numbered poker cards, which btw were not that fibbonnacci. Methodological nonsense taken to the extremes when all that you really need is an agile process and fluid communication. But methodologists gotta make a living, and since they've lost all their prog skills ( assuming they even ever had some) then Scrum mastering fills the gap...

i want to throw up when hearing 'agile'

QuoteOriginally posted by: Cuchulainnedit: Scrum idea does have a social aspect in that it gets people talking. But where it fails imo is when it pretends to / replace design experience.If you build a house, you don't want the scrum team scrumming arount the coffee machine every morning deciding what to do next. The architecture should drive the project. If you don't have an architectural vision, then oh boy watch out.In one sense, s/w design has a long way to catch up on h/w or even engineering design.On a side note -- at least for some kinds of software, the International Space Station might be a better analogy than a house.

Agile, you said?

QuoteOriginally posted by: CuchulainnQuoteOriginally posted by: quantmehQuoteOriginally posted by: CuchulainnDoes the book discuss Scrum??? Don't like that stuff.if you say this out loud on a job interview - you're a toastThanks for the tip; I'll remember that. RAOFLMAO ANHACITPScrum/agile etc. What it comes down to is people don't know what solution they want and what the requirement is. I know this is old fasioned the only solution that these metholologies give are to move projects forward which are stuck due to political issues. To paraphrase: Agile is the continuation of development life cycle through other means.

unless you´ve been coding nothing but firmware in a Factory, then immutable requirements make much sense as grammatical demonstrations of number theory conjectures. In the real world, especially in finance, requirements do change a lot, always, everytime, hence, "agility" is a must. Now whether that needs to be served in a "methodological package" or just implemented using good ol´common sense, then that´s an altogether different question.