I was having a particularly rough day today, and just had a feeling that you would be able to help. Thanks for this post, as it has reaffirmed my position to delete and remove as much crappy dead software as possible. This blog post is going on my internal team wiki as we are all new owners of some really old crappy, crufty stuff that has a lot of opportunity for improvement.
Many thanks for yet another gem.
/Em
Back in the day i managed to crash an A17 then Unisys largest mainframe by doing agressive testing
Chinese did not do any test during software development?
That’s not a bad solution, except that in a medical environment, the glaring bug is liable to result in someone’s injury or death. Medical is a 0%-margin-of-error industry (even though it doesn’t seem like it sometimes…)
In a non-medical environment, this offends the people who think there are 0 sexes. Or 9. Or an infinite number of gradations.
And what of the people who believe that you can be one sex Monday, a different sex Tuesday, and yet another Wednesday?
All I can say is that I’m terribly lucky to have a single good tester where I work. She’s vicious.
Despite the fact that we barely have automated builds, no automated deployment procedure, no integration testing framework, heck we don’t even have a modern version control system (we’re still using CVS on a Win2k box), we still manage to produce usable code, because our tester whips through common and edge cases like you wouldn’t believe.
“politically correct” is a synonym for “not an ignorant neandertal”.
“If this causes you to hyperventilate and have your poor feels hurt, too bad.”
Project much.
“born with certain parts”
Biology fail.
It obviously matters a whole lot to reactionary trolls.
Living in Australia (southern hemisphere, GMT+10) I’ve lost track of the number of US software packages over the years that have crashed or failed because I had the temerity to enter a negative latitude or a timezone that the “everywhere is Seattle” software authors couldn’t handle. It’s generally getting better, but there’s still so much room for improvement! Oh yeah, and that entire ridiculous business of “everyone has exactly one first name, one last name and one middle initial” … let me tell you about a friend who had to go through four years of university with the middle initial X on her student card!
UniSA still uses the character Y to fill in gaps in usernames for students without a middle initial or short family names.
Citing religious confabulist C. S. Lewis while railing against “those who see the world as constructed by belief” is quite ironic, and more projection. But hey, we’re off topic, and have been since some misogynist reactionary ideologue took us there. Ta ta.
You’ve summed up the troll well.
I recently talked to a tester at Google who referred to this as a high “paranoia factor”, and bemoaned the fact that so many developers are so trusting. One should suspect bugs lurking in every nook and cranny, especially in error handling.
“Paranoia factor” is exactly right. I’ve learned a lot from our tester, mostly about taking responsibility for verification of code vs. spec and spec vs. stakeholders’ ideas. She declared herself “Executive in Charge of Circling Back About That” a while ago, and that’s what she spends most of her time doing. It doesn’t help that our stakeholders change their minds more than coke-addled howler monkeys.
Strongly related! The giant list of “naughty strings” for testing!
I wonder if the LTR strings handling there already takes care of things like the ones which crashed iOS back a couple years:
Or if that list includes such known bugs. 
I may be reading too much into this, but there seems to be a tacit assumption here that these issues can only be dealt with through testing, but programmers always have the option of thinking about every one of the issues listed here, at the time they first write the code or while thinking about design. Of course, that is not an alternative to testing; in fact, I quickly learned (before the Agile Manifesto) to test early, often and with automation, but all too often, I see people assuming that writing what is essentially a guess at a solution and then fixing it is the only way to write software.
I think it is important to strive to be right from the beginning, if only because there are certain areas (e.g. concurrency, security) where it is well-nigh impossible to test-and-fix your way out of a bad design.
Reading it made me think of something I tried to explain to someone else once: all applications have pretty much infinite paths through them. You will never remember them all - heck you will never even find them all. That is why we need automated tests, because they can remember this stuff way, way better than we can.
Hey Jeff, just wanted to know if you have any go-to debugging tools, or do you just use the debugging options used in your chosen IDE? I have heard a lot about GDB, but was wondering if there is anything else out there worth exploring?
It would be interesting (and presumably computationally really hard) to have “smooth” timezones - that is, the farther you go east or west, the more your current time changes. In a smooth manner directly corresponding to when, at this point of the surface of the earth, the sun would be closest to directly above you in the sky.
Presumably that would add a lot of complexity to synchronizing your time of arrival at a given point from various starting points though.
Actually…that’s how it used to be! Every town set its own local time based on when local solar noon was.
That worked great when the fastest way to travel was by horse, and nobody really expected someone from out of town to arrive at a specific time, or to take an action where they were at a coordinated time. But you can’t run a railroad, that way! As soon as rail and telegraph became a thing, coordinated time became more important. Our entire modern time zone system is the direct result of agitation by the railroads companies, to make the job of creating and publishing schedules easier!