If you haven't made a guess as to the answer to my code question, go to the entry first.
This answer was the most complete from the internal developer mailing list. It came from the group manager, who hasn't done any dev work for a while now. But apparently retains some of his coding skills.
Besides doing nothing of any value (putting a null where a null already is)? Or, if the comment is right, scanning off the end of the XML string to find the first zero in memory (or faulting), then writing zero to that memory (which could now hold some other value), or some memory way earlier (if we went negative on the int)?
Another dev friend of mine here summarized what the code does with this pithy description.
let's go search for a zero in memory and write a zero there
Of all the answers I got to the question internally, I got seven (7) incorrect answers, including one from a lead. The sad thing is that our dev process is so lax that this little number got through.
From another dev here I got this comment after I posted the answer.
A more interesting question to ask is: how did this code get into the code base? Several things might have gone wrong:
- The dev didn't understand the code
- The dev didn't test it
- The dev didn't have it reviewed or the reviewer missed it.
- No lead approved it, or the lead failed to understand it.
It's fun to point out these examples, but we need to understand why this happened, and develop processes to guard against it, or find out why our current processes failed to catch it.
</soapbox>Part of the problem is that we have such a large code base and such a large amount of work to do that most leads tend to do very little reviewing of code. They may glance at something, but it takes a lot of time to understand out code base so they look only for design level issues, most of which can't be fixed anyway because of a poor internal code architecture. And until recently, core areas were wide open. Anyone could check anything in. We've locked down all core areas now though.
I think I need to make an entry on some ideas I have about software process. I should note that these ideas were part of the reason I got fired from Syndeo Systems a few years ago. Basically, my boss got tired of me advocating process. We had none and it was hurting us. He thought process would slow us down. Since I was nominally the dev manager, it was my call. Not really though, as I got fired for butting with too many heads over such stuff.