An excellent introduction to OO software design from a formalist viewpoint, based around, but not dependent on, the Eiffel language.
An excellent introduction to OO software design from a formalist viewpoint, based around, but not dependent on, the Eiffel language.
rating : 2.5 : great stuff
Denotational and axiomatic semantics for the masses.
Eiffel has been called a “RISC language” because of its design simplicity, consistency and blend of powerful mechanisms; an object-oriented structure based on classes; multiple and repeated inheritance; information hiding; assertions to guarantee, document and test the correctness of software components; strong typing backed by support for generic classes; dynamic binding; a highly dynamic run-time model supporting garbage collection; renaming and redefinition facilities; disciplined exception handling; support for persistent objects.
Because of its emphasis on the industrial production of reusable software components, rather than one-of-a-kind applications, Eiffel has been heralded as the language for the “new culture” of software development, based on reuse, which promises to revolutionize the field. Written by the principal designer of Eiffel, this is the first book to cover the language in full, incorporating the most recent developments of version 3. It sets a new standard in programming language specification by combining a pleasant and pedagogical style – with detailed explanations of all the important concepts reinforced by more than sixty figures and hundreds of examples – with a high degree of precision and formality in the paragraphs defining the syntax, validity and semantics of individual constructs. This makes it suitable for novices as well as advanced users and implementers.
The book of the language, from its inventor, written in his usual discursive style. A good read for understanding the language; rather harder, but still possible, to use as a language reference.
A complete reworking of the first edition, and extended to cover new areas. Some think this long-awaited second edition is not an improvement on its slimmer original. I haven't read it yet.
rating : 2.5 : great stuff
review : 8 January 2015
Agile methods are one of the most important developments in software over the past decades, but also a surprising mix of the best and the worst. Until now every project and developer had to sort out the good ideas from the bad by themselves. This book spares you the pain. It offers both a thorough descriptive presentation of agile techniques and a perceptive analysis of their benefits and limitations.
I’ve been a fan of aspects of Agile Programming ever since I first read about it. In particular the incremental style works very well in building software to support scientific research, where you really don’t know what you need to do next until you have run the prior experiments and come up with the next hypotheses; the discipline of YAGNI (“You ain’t gonna need it”) can save a lot of time and effort here. The “always have a working system” (continuous integration) part also works well for student projects, with their rigidly time-boxed hand-in dates. However, I also have a background in formal methods, so some of the more seemingly heretical and potentially “hacky” bits of the process do raise an eyebrow.
That’s where Agile! comes in. Bertrand Meyer is in the “strong software engineering” camp, strong on specification and design, and the inventor of “design by contract” in the 1980s, an approach of which I’m also a fan. What is he going to say about this new approach?
Unsurprisingly, he thinks some of it is bad; very bad. More surprisingly, possibly, he thinks some of it is not just good, but even “brilliant” (his term). He goes through the various components of the various Agile approaches, describing and critiquing them. He puts most emphasis on Scrum, with which he is most familiar (even being a certified Scrum Master), but also covers Crystal, XP, and Lean.
In summary, the ugly includes the lack of upfront specification and design (even allowing for the fact it will change later) and specifically user stories as the basis for requirements and test-driven development as the basis for design; the hype includes pair programming and collective code ownership the good includes refactoring; the brilliant includes iterative development, continuous integration, and test first development (associating a test with every piece of functionality).
His argument for up-front specification and design includes the need for finding good abstractions, which will not automatically emerge from a test-code-refactor cycle. A specification is more abstract than a test suite, because it covers all the cases (thereby removing the problem of induction, or inducing the general from the specific). Similarly, he argues that user stories are to requirements what test cases are to specifications, including the same problems of lack of generality and completeness. We presumably need another aphorism to complement Dijsktra’s famous observation that testing can show the presence of bugs, but never their absence. Maybe it should be something like user stories can show the inclusion of functionality, but never its omission.
My only peeve about the book is some of the typography. Occasional paragraphs that are “asides” are set in a smaller font size. Every time, I initially parsed these as quotations, and had to backtrack. Notwithstanding this minor point, Agile! is an excellent thoughtful critique of Agile methods. Although Meyer introduces and describes all the concepts he critiques, I don’t think it is a stand-alone text, as those descriptions are somewhat brief. However, is should be required reading for anyone using, or about to use, an Agile approach.
At 170pp, it is a fast, if dense, read. I laughed out loud on several occasions. For example, he comments on the picture accompanying the agile manifeso:
Introduces The Seven Sins of the Specifier
