Saved by the Notes - I attended a meeting called by the new manager. He compiled a list of things he thought we going out in the next release. He wanted to make sure all the d...
I have been instructed to keep an eye on the schedule to ensure there are no errors. I especially pay attention to the due dates for tasks assigned to me or my team. This should be pretty simple. For every major change we code, I provide detailed high fidelity estimates for the work. You could just take those estimates and plug and chug the schedule.
The high fidelity estimates actually make my schedule review real easy. I look at the tasks and due dates on the schedule. Then I just do a quick calculation based on my estimates to see if they are in line. If they are not, I just raise up the concern, referencing my original estimates.
I figure my job is to alert everyone to any crazy schedule failures. That way there is no surprise when someone thinks that a task will finish when it is actually taking a whole lot more time. Obviously something is going to have to give. Most likely it will be a schedule change to reflect the reality of the development durations. I expect there to be some pain before this can be achieved though.
The developer did some research. We were all surprised at what he found. The character set had a value of "Use Multi-Byte Character Set". Ooops. We pretty much do single byte characters. You know, the old C-style strings. That wrong setting was causing memory leaks. Who knows what other problems this mismatch was causing.
This seemed strange. You get Unicode as the default setting when you create a project. Somebody must have changed that to MBCS. Why? Did they not know what this setting controlled? This is just disturbing. Time to look at the settings for all our Visual Studio projects. We really should have been detecting this earlier. Memory leaks are bad and need to be plugged.
I would prefer that ratings be taken a bit further like they are at select companies. The bottom performers are periodically purged from the company. That might seem a bit radical. But you want to keep your top performers around and happy. It does not help when you keep dead wood on a project or even in the company.
I read an article by Vanity Fair where they interviewed a lot of Microsoft employees. Apparently Microsoft does not like stack ranking to evaluate employee performance. It pits developers against each other. Strange. You would think Microsoft developers would also want such a ranking. At my company, the only time relative rank comes into play is when they evaluate your pay raise. If you make a lot less than your peers, you get the opportunity to catch up during a pay modification.
Installshield has the functionality to deal with silent installs. You create a response file to generate answers to the questions that are normally posed to the user. A developer has been recording his actions to generate this response file. However he has discovered that whenever he makes a change to the InstallShield project, the response files become invalidated. He need to go back and recreate the response files.
The developer in charge of this is tearing his hair out because of this. I joked that we might need to create a program that automatically regenerates the response file every time the InstallShield project is touched. Feels like two levels of indirection.
My developer colleague thinks that the InstallShield objects have a unique GUID that is regnerated every time you mess with the project. He further believes that the response file data is tied to a specific GUID. If that is the case, this is indeed pure insanity.