4 ms·

In FrameMaker's "Book" functionality, where you can stitch together a bunch of individual chapter files into a larger document, there's a very edge-case possibi

In FrameMaker's "Book" functionality, where you can stitch together a bunch of individual chapter files into a larger document, there's a very edge-case possibility of hitting a situation where there's no solution to the pagination (say that Chapter One has a forward reference to "(See page 57.xiv)" but added text puts the tagged info on page 57.xv, so the reference gets automatically changed to "(See page 57.xv)", but that text is shorter, so there's a slim chance that the reference has to change back to 57.xiv, but that makes the text longer again, which pushes the tagged info back to page 57.xv, ad infinitum). Clearly, though it never happens in the real world, my code had to detect if a document seemed to be looping this way, and since I never expected anyone to see it, it just issued the one-word error message "Degenerate", with the intended meaning that "this document has hit a degenerate case". Well, of course some customer found a bug that triggered the message, and called tech support, irate that our software had called him a degenerate.

zvr 5y ago
Wow, that was you? I've heard the anecdote decades ago (probably read it on Usenet or in a book) but never thought I'd learn more nor find the person responsible for it... Thanks -- and you might be interested to know that the example has been used in many lectures/presentations.
- drfuchs 5y ago
  Well! Yup, "Book" internal design and implementation was all me. I don't think anybody else at Frame even knew the message existed, until that fateful day. The bug that caused it to come up was also mine. Any pointers to lectures/presentations? That was news to me! So as to not leave the wrong impression: The entire user-visible document model and feature set of FrameMaker were ultimately the responsibility of one person (V.P. Engineering David Murray), who kept all the features mutually consistent, and the product as a whole "just right" as far as being not too complex or confusing while still being powerful enough for users to be able to do what they needed to do, and have an accurate mental picture of how everything worked. I believe that this approach was essential to the success we had; I'm always astonished when hearing in passing how things go in some other places, along the lines of "so programmer X decided to put in feature Y, got a quick OK from management, and then went off and designed the UX/UI all by themselves, implemented the whole thing, and merged it on in..."

zvr 5y ago

Wow, that was you? I've heard the anecdote decades ago (probably read it on Usenet or in a book) but never thought I'd learn more nor find the person responsible for it... Thanks -- and you might be interested to know that the example has been used in many lectures/presentations.

drfuchs 5y ago
Well! Yup, "Book" internal design and implementation was all me. I don't think anybody else at Frame even knew the message existed, until that fateful day. The bug that caused it to come up was also mine. Any pointers to lectures/presentations? That was news to me! So as to not leave the wrong impression: The entire user-visible document model and feature set of FrameMaker were ultimately the responsibility of one person (V.P. Engineering David Murray), who kept all the features mutually consistent, and the product as a whole "just right" as far as being not too complex or confusing while still being powerful enough for users to be able to do what they needed to do, and have an accurate mental picture of how everything worked. I believe that this approach was essential to the success we had; I'm always astonished when hearing in passing how things go in some other places, along the lines of "so programmer X decided to put in feature Y, got a quick OK from management, and then went off and designed the UX/UI all by themselves, implemented the whole thing, and merged it on in..."