Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror

Comment Every mistake is visible but no consequences (Score 1) 391

Simple: (Almost) every mistake a programmer makes is visible somewhere, but there's actually very little consequence to it. Put another way, bugs happen all the time, people notice but it doesn't matter.

Off by one, program crashes...user restarts it. Miss a "delete" somewhere, program runs out of memory (eventually), user restarts it. Some tiny bug corrupts user data, company fixes it, issues apology, life goes on. With a few (notable) exceptions, when a programmer makes a mistake, life goes on. Very few of them have any real consequences, but they are visible. Someone can't enter in their company name because it contains a digit. Another can't enter their own real name because it contains an accented character.. Tab order is messed up. This field is misaligned with that one. So what?

Arguably, these are visible, but mistakes in other fields may be nearly as common, and with little consequence, but aren't VISIBLE. Construction worker puts 1 nail into a 2x4 instead of 2. Nobody cares. Another neglects to tie the rebar together in a few places. Nobody notices or cares. The bridge is slightly out of level or square due to some miscalculation and...cars can still drive on it just fine. Errors happen in every job, but most aren't visible.

For the most part, we don't have enough redundancy in software resulting in mistakes being a LOT more visible. But there's still little consequence - users will work around it it, companies fix (and sometimes even apologize) and nobody up nor down the chain loses their job or even gets reprimanded.

If bugs were less visible, they'd still happen but fewer people would know.

If there was more consequences to any given bug, then we'd have a lot better practices in place to make sure they didn't happen (and software would be even more expensive than it already is).

Comment Created a patcher for our own software (Score 1) 145

Once upon a time I was part of a company acquired by a parent company. Sometime thereafter, parent company's product started displaying an error message and then exiting on all of their customers' computers at the same time. Apparently the (hard-coded) license key for some 3rd party component had expired and as a result hundreds if not thousands of people couldn't do their jobs. The affected product Team Leader's fix was to get a new license key, replace it in the source, compile and then get everyone on that new version as soon as possible. The problem was that good ol' parent company didn't have great source control procedures nor a build server prior to acquiring some real developers (us) so there was a huge variety of versions of the product across all of their customers, some of which were known to contain custom one-off features and changes that potentially never made it into source control in the first place... Also the product couldn't be upgraded without also upgrading some or all of the server pieces too. It was a big mess with potentially days of downtime to clean it up and their customers were losing money by the minute and rightfully PISSED.

My solution was to create a little utility that looked for copies of the product in the usual places and replace the expired license key (stored in UTF-16 in the .exe) with the new one. Since the keys were the same length, it worked perfectly and the support team was able to deploy that to all of their customers in the matter of hours.

Slashdot Top Deals

"Show business is just like high school, except you get paid." - Martin Mull

Working...