One thing that annoys me though about most programming language books is how raw they often are.

  Probably constrained by time, authors and book teams seem to invest less on editorial stuff and teaching methodology and more on explaining details of technical and behind the scenes stuff. This often results in more manual-like books where you have a great wealth of material that you are not able to exploit anyway because of, well, lack of time. I am not sure I can invest time in reading 500+ manual of a new, or at least non mainstream, language that I might decide not to use by the end. 

I am not saying here that technical and behind the scene stuff does not matter, quite the opposite. I just think that manual, important it is, should not be the introduction to the programming language. A rather 100 to 200 pages brief book that is carefully edited to introduce paradigm, concepts, and strengths of the programming language is a more attractive choice , accompanied with a wordy but well organized reference book with examples and more in-depth explanation of language features. I guess this is a more pragmatic approach to programming language learning in the presence of WWW and Google search.

PS: I personally find Paul Hudak’s Haskell book a very good example of an enjoyable, brief, nicely and carefully edited programming language book. Also LUA’s programming book is nicely done.

Making the tough decisions early make the other decisions easier
To do agile you should be standing on a firm foundation
Stability != Static

YAGNI?  not extremely!
Fainting Ignorance :Don’t Play dumb! If you know some stuff celebrate that you know it and put a peg in the ground.
It is ok to know stuff, it is alright.

James O. Coplien has recently argued that today’s industry is based on buzzwords and checklists. The use of some techniques and methodologies, TDD for instance, has become “a religious issue”. This prevents from inspecting possible tradeoffs and focusing on finding solutions that would be the most appropriate and the most cost-effective .

“For some reason, we have invented and are following religions […].” This is how James O. Coplien describes today’s industry which, he believes, is based on buzzwords and checklists rather than on thinking, inspection and efforts to find solutions that would be the most appropriate and the most cost-effective for a given project:

How much thought did you put into the tradeoffs of the last technique you brought into your organization: Ajax, TDD, On-Site Customer, or other buzzwords? Did you research its track record? Or did you go to the buzzword yellow pages?

James uses the example of the debate around TDD which has occurred in the blog space in the wake of Jaoo 2007 conference. When the discussion focuses on what approach to testing is the best (i.e. TDD or acceptance testing), it essentially addresses the wrong question. It obfuscates the real objective which is “to deliver what the customer wanted while optimizing quality” and to create value for the client. Testing is what we have on today’s checklist for quality but it is far from covering all the issues that actually affect quality:

Quality suffers if you misunderstand what the customer wanted, or if the code has internal interactions that are difficult to foresee, or if local code violates array boundaries or uses untethered pointers. It also suffers if the interface makes it possible for the user to commit errors, or if it takes too many keystrokes to enter a small amount of common information.

Focusing on quality requires considering every weapon in the arsenal:

That means using Use Cases (which are an Agile way of engaging customers […]) instead of XP-style user stories (so you understand feature interactions up-front), doing pair programming or desk-check code inspections, doing design by contract, driving the process with usability experts and doing good usability testing, and a host of other things.

Coplien emphasizes that it is impossible to do everything and that it is “a matter of cost effectiveness”. But being focused on techniques and driven by buzzwords we get stuck in practices that might not be optimal. The use of some techniques and methodologies, e.g. TDD, has become “a religious issue”, according to James:

We are told that you have to do TDD to be a professional […] and yet are given no reason to believe this, no substantiation, and no evidence. Just believe.

Coplien argues, for instance, that “integration and system testing have long been demonstrated to be the least efficient way of finding bugs”, that TDD “deteriorates the architecture”, and that “acceptance testing is orders of magnitude less efficient than good old-fashioned code inspections, extremely expensive, and comes too late to keep the design clean.” But he stresses how difficult it is to engage a challenging discussion on such “religious” topics because any criticism is met with a lot of emotion.

People have tied their Agile success to their introduction of TDD practices into their work. It’s the one thing they can do as individuals rather than as an enterprise.

Coplien advocates for focusing on quality rather than testing and, more generally speaking, on thinking rather than checklists. He highlights however that “sorting these things out requires a system view”, which often times lacks in today’s industry. He believes that “New Age Agile movements consistently move away from” systems engineering. According to Coplien, “one root of the problem lies in modern education, which has increased its focus on technique and reduced its focus on thinking.” Today’s students “fewer and fewer understand software history” and “have stronger memories […]on exactly when to use --v and when to use v-- than they recall anything about logical design.”

Close links which exist between academia and industry are also a part of the problem. Universities tend to adapt curricula to industry’s needs in order to facilitate students’ placement. Hence, it becomes difficult for academics to challenge predominate views, probably “as difficult as it was for Newton” to prevail “with new insights on the working of the universe”:

In fighting the broad misunderstandings that industry has chosen to adopt from selected interpretations of Agile, SOA, and programming language buzzwords, we face no less a religion, and no less threat to our cozy industry-financed academic positions, than he did.