Best 18 quotes of Bertrand Meyer on MyQuotes

As Mr. Nagle so competently points out, almost no one uses Eiffel; in fact until recently there were only 9 users. But now a 10th person just started, so we are holding a conference, appropriately titled the TENTH Eiffel USER conference, to celebrate.

Careful as they may be, developers of Eiffel libraries will always run into cases in which, after releasing a library class, they suddenly experience what in French is called esprit de l'escalier or wit of the staircase: a great thought which unfortunately is an afterthought, like a clever reply that would have stunned all the other dinner guests - if only you had thought of it before walking down the stairs after the party is over.

C++ is the only current language making COBOL look good

Constants are widely known for the detestable practice of changing their values; we should prepare ourselves against the consequences of such fickleness

Correctness is clearly the prime quality. If a system does not do what it is supposed to do, then everything else about it matters little.

Eiffel borrows quite openly from several earlier programming languages and I am sure that if we had found a good language construct in C we would have used it as well.

I have always felt sympathy towards the biologists who accept to debate creationists. Now I also understand them better; one can fight opinions, not articles of faith.

Incorrect documentation is often worse than no documentation.

I think Smalltalk is inappropriate for serious industrial developments. After all, run time is a little late to find out whether you have a landing gear.

Perfect reusable components are not obtained at the first shot.

Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.

There are only two things wrong with C++: The initial concept and the implementation.

The role of a trainer or consultant is to empower the customer, not to make himself indispensable

Writing a class without its contract would be similar to producing an engineering component (electrical circuit, VLSI (Very Large Scale Integration) chip, bridge, engine...) without a spec. No professional engineer would even consider the idea.

You can either have software quality or you can have pointer arithmetic, but you cannot have both at the same time.

The Scrum idea of a separated Scrum Master is good for Scrum, but not appropriate for most projects. Good development requires not just talkers but doers.

To focus on the visible at the expense of the essential is irresponsible.

Worse yet is the rejection of upfront requirements. The basic observation is correct: requirements will change, and are hard anyway to capture at the beginning. In no way, however, does it imply the dramatic conclusion that upfront requirements are useless! What it does imply is that requirements should be subject to change, like all other artifacts on the software process. [...] The agile advice here is irresponsible and serious software projects should ignore it.The sound practice is to start collecting requirements at the beginning, produce a provisional version prior to engaging in design, and treat the requirements as a living product that undergoes constant adaptation throughout the project.