After a long dry spell... you post twice in one day? No, that's not it.
After fighting with the product build, unit tests, and automated smoke tests for two days and you finally get the build working and start allowing commits to the repository... the first commit after all of that breaks the build again...Gahhh!! It's a good thing I was there to warn the culprit before the engineer who has spent the last two days (and nights) getting everything back in shape, came storming into this guy's office... armed to the teeth with one of the monster Nerf cannons laying around here. The hallways sure did light up for a few moments ;-).
I'm highlighting all of this because no matter what processes you put into place, and how many emails, wiki posts, meetings you have, ultimately it will boil down to simple human error. Just like the old adage, the more foolproof you make something, the more the world seems to hand you smarter fools :-). I know I've certainly been just as guilty as the next guy of breaking the build. Are there any of you out there with some great (infamous, funny, or just plain scary) stories of how against all odds, a member of your team managed to bypass all the safeguards and promptly broke the build? We all have stories of some "former team member" who did some of the craziest stuff, but what about your most embarrasing moments? These are the kinds of moments that, while infuriating at the time, you will look back on and find the shear humor and irony of the entire situation. What is your WTF story?
We have a developer fines jar, where developers are fined $1 anytime the nightly build is broken. These funds are then used to shout the team out to lunch every once in a while.
ReplyDeleteI am often the most frequent contributor to this jar, and here's the main reason why. I'm the sole Compact Framework developer in the company, and our CF product has code which is shared between the CF and full desktop version.
While it is best to code to the lowest common denominator, I find it much quicker to code and debug the desktop version. So in times of great stress and urgency (are there ever any other times? ;-)), this is the approach I take.
As a result it's not uncommon to develop solutions which take advantage of classes or methods which don't have implementations on the CF version. And if you neglected to test both versions (you may have slated tomorrow to do your CF testing), you only find this out after checking in the code and coming in the next day to find you've broken the build, and have to reach into your pockets again.
Back in the good-old DOS days, I used Norton Command and Norton Tools, including one handy tool to wipe the erased space of your hardisk (a few times, with 00 or FF or random values). This WipeDisk tool had a /E switch to ensure it would only wipe the ERASED space. And it works fine every day or week I ran it.
ReplyDeleteUntil one day when I forgot to add the /E switch... Who ever reads the confirmation messages? Just press <enter> to continue anyway...
I haven't run WipeDisk since (and yes, it had done a really good job indeed)...
Groetjes, Bob "back-up?" Swart
More than once I have checked a change to a dialog or window that touched both the .pas and .dfm file, but only moved one or the other onto the build branch. Which doesn't actually break the build, it breaks loading the dialog at runtime, and if nobody thinks to test opening that exact dialog, it might possibly get shipped. The worst time I did this was with a printing progress dialog. The unit testing for printing ran like a champ, but when a user tried to print from the app, blammo!
ReplyDeletekz
Many, many years ago, back in Paradox for DOS, I could not get this one piece of code to work. Debuggers weren't so hot back then, so you sometimes traced code progress with messages. At about 3 in the morning, I put in a message to notify me if the code worked - the message in big bold red font was "Finally, this F%#ng code is working. Hallelujah." - but not the sanitized version. The code was on the network. I went to bed, came in late the late the next day, and lo and behold one of our early riser developers had built and deployed the code to our military client as part of a bug fix. Oooh, the phone calls I got that day (no email back then)...buy hey, at least the code was working, right?
ReplyDeleteWould use this chance to ask a question...
ReplyDeleteTDataSet internals is on of the most undocumented and misty part of VCL. And...
And it made me wonder, how do Watch and Inspect do lay hands over those non-published properties/members ?
Is seems Delphi IDe keeps very detailed debug info somewhere within and have some interfaces to query for it.
Can them be exposed ?
This would allow the expert, that, i think, would help to debug components sometimes.
Make a snapshot of a component at some time, then make another snapshot after couple of statements and analyze what had been changed. Repeat with another statements that looks innocent but later makes component go crazy - and again diff the changes and compare them.
But... how to query all that information in, say, Delphi 5 ?