4 ms·

I guess someone who implemented this passed a whiteboard interview...

• susam 10y ago
  You were probably being funny. However, if I take this comment seriously, I find it unfair. Large products these days have so many moving parts that it is not always easy to reason how one part of the product may cause mysterious, interesting and incorrect behaviour in another part of the product. I wouldn't be dismissive of the calibre of an engineer just because he or she introduced a silly looking bug. One really needs to understand the root cause of a bug before one can judge the skill of the engineer behind it. However, the fact that they do not fix this bug and instead offers a workaround as a resolution might offer some clues about the quality of the code and architecture of the product or their priorities or both. As part of my job, I have discovered several bugs in Microsoft products or APIs that were blocking projects I was working on. When I filed service requests (my then employer had a premier support account with Microsoft), very smart support engineers from Microsoft were assigned to my service requests. By the way, I am calling them smart because they understood the issue accurately and quickly; that in itself could be a lot of trouble while dealing with support engineers of some companies. I remember two such service requests in particular. 1. An incorrect implementation of WebDAV protocol related to WWW-Authenticate header and redirects. It was too long ago to remember the exact details but the issue was similar to but not exactly same as https://support.microsoft.com/en-us/kb/922722 https://support.microsoft.com/en-us/kb/922722. We were trying to write some software that allows MOSS to be integrated with our SSO products. Since it was not the exact same issue as the one described in the KB article, the workaround provided in the KB article did not work for us. The response provided to me by Microsoft Premier Support was that the fix for the issue was considered multiple times in the past but due to the technical challenges involved, the changes were not approved internally in Microsoft. 2. ReadEventLog ( https://msdn.microsoft.com/en-us/library/windows/desktop/aa363674(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/aa3... ) fails with error 87 under certain conditions when dwReadFlags has the EVENTLOG_SEEK_READ flag set. The resolution they provide at https://support.microsoft.com/en-in/kb/177199 https://support.microsoft.com/en-in/kb/177199 is to use the EVENTLOG_SEQUENTIAL_READ flag instead. While that sounds acceptable in theory, when I actually tried it out, I found another bug there. When the event log file at the remote system is 2 MB or larger, ReadEventLog with EVENTLOG_SEQUENTIAL_READ flag did not honour the nNumberOfBytesToRead parameter at all. No matter how large a buffer we allocated to read events, due to this bug we would get exactly one event for every ReadEventLog call. When this issue does not occur, we can get hundreds or thousands of events in one call. But due to this bug, we get one event per call. These two bugs together caused such a major performance issue in our product that it made our product practically unusable in some scenarios. Once again, the Microsoft support engineer began working on the service request very swiftly. He wrote his own code and replicated the exact problematic behaviour we were facing. However, he could not offer a resolution; he said that the issue was present in a very complex part of the product and it was very unlikely that the product team would ever spend time on fixing this bug. These responses led me to believe that there is a problem with the code quality and architecture of their products that makes bug fixing difficult for them. In my 10 years of career, I have never worked on a product where code complexity was cited as a reason for not fixing a genuine bug.
  • mfoy_ 10y ago
    People have whole blogs dedicated to finding workarounds for quirks in Microsoft products. It's always an adventure.