The problems with @file that have just resurfaced show how hard it can be to manage complex engineering projects. I got blind-sided by this problem, despite the fact that it had been dealt with before.
The problem was compounded by the fact that the unit tests for @file never failed. Looking at them just now, I see that they silently became irrelevant sometime during the course of 4.7 development. Indeed, the unit tests generate file-like sentinels, and then verify that Leo writes those sentinels as expected. But the new @file == @thin code forces thin-like sentinels. Presto, the old unit tests began to test the wrong thing. This shows, quite clearly, that unit tests can create a false sense of security. If there is an automated way to avoid this trap I don't know what it is. Edward P.S. In order to make progress, I relentlessly focus on closing issues. But any mistake in doing so can create a time bomb. One such bomb has just exploded. Here, with Leo, the stakes are relatively small. With the Space Shuttle the stakes are much bigger, and the engineering difficulties much larger. It is all too easy to criticize the management mistakes after they came into sharp focus after the fact. At the time, however, the mistake was only one of thousands of decisions. Could any of us honestly say we surely would have done better? I doubt it. EKR -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
