Bug Psychology

re: Bug Psychology

jcoehoorn — Mon, 01 Jun 2009 18:37:34 GMT

Looks like this has been on your mind a lot recently: it's basically a longer version of something I saw you write on StackOverflow recently:

http://stackoverflow.com/questions/921180/c-round-up

Indeed, that was the inspiration. -- Eric

re: Bug Psychology

Jonathan — Mon, 01 Jun 2009 20:45:56 GMT

Of course, you are still using cases. It's just that by focusing on one VT_DATE at a time to translate it into your sensible format, you only have to deal with 2 cases, rather than the many cases that come from the combined properties of 2 VT_DATEs, apparently so many they have not been successfully enumerated.

But why were you using the horrible VT_DATE format in the first place?

VBScript uses that format to be compatible with VB. VB uses that format to be compatible with OLE Automation. OLE Automation uses that format to be compatible with Excel. Excel uses that format to be compatible with Lotus 1-2-3. With hindsight, the right thing to do would have been to say "Lotus chose a lousy way to represent dates, let's write a translation tool that turns their goofy date format into something sensible and industry-standard". But we did not do so when we had the chance and we're stuck with it now. -- Eric (PS: As a historical note, VB and OLEAUT were owned by the same team, so it is perhaps not quite fair to say that VB does it that way "because of OLEAUT". They both evolved that behaviour at the same time.)

re: Bug Psychology

h t — Mon, 01 Jun 2009 21:25:26 GMT

That's amazing that the Lotus bug dictated the new Day One, unbelievable! I just read about a 1000 line Switch block the other day. So the case by case approach is very much alive and cultivated.

re: Bug Psychology

DRBlaise — Mon, 01 Jun 2009 22:45:12 GMT

Why even have the unnecessary (vtdate >= 0.0) check when everything can fall into 1 case:

return DatePart(vtdate) + TimePart(vtdate);

Good point; my way is a potentially premature optimization. I'll fix it. Though in fact, given that probably 99.99% of dates we see are positive, and given how tight the rest of the code was already, it was actually probably a reasonable optimization to take the early out. I don't recall the details; this was 13 years ago after all. - Eric

re: Bug Psychology

Grant — Tue, 02 Jun 2009 13:48:19 GMT

The Lotus bit reminds me of this story: http://www.astrodigital.org/space/stshorse.html

Finding a way to replace useful but flawed code seems to be one of Microsoft's greatest challenges.

re: Bug Psychology

configurator — Wed, 03 Jun 2009 04:05:04 GMT

So, do these candidates that do *exactly the same as your smart coworkers* fail immediately or do they have a chance?

When I specifically tell the candidate "this problem is difficult to solve by cases, consider transforming the data into a better format for arithmetic", and they keep on trying to solve it by cases, no hire. When I write a bunch of interesting test cases on the board and they write me code that does not pass two of the four test cases, and they tell me it is correct, no hire. Heck, I've had candidates who were unable to write the code that computes the absolute value of the difference between two doubles. Those people will not be successful on a compiler team. No hire. -- Eric

re: Bug Psychology

Faraz — Wed, 03 Jun 2009 07:30:48 GMT

"we just found out that the product name sounds like a rude word in Urdu"

with Urdu as my native language, I would love to hear this story.

Regrettably, there's no story there. I just made that up as characteristic of the sorts of geopolitical issues we sometimes run into. Usually we don't have too much difficulty with geopolitical issues on the programming language tools teams, but anyone who, say, displays a map of the world as part of their user interface is required to ensure that the map is carefully designed to not implicitly "take sides" in geopolitical disputes. I'm sure you can think of examples. -- Eric

re: Bug Psychology

Denis — Wed, 03 Jun 2009 11:10:32 GMT

"...immediately they’d write down code for another special case, rather than stopping to think..."

...they are just trying to SERVE!!! How many times have we all been told that SOFTWARE DEVELOPMENT IS A SERVICE INDUSTRY? :-) Some people just confuse "service" with "subservience" or -- worse -- "servility". So, I've writtent some buggy code?! Sorry, Master! Right away, Master! Whatever you say, Master! Here is another "if-else," Master...

A sad state of affairs, I'd say... :-(

@configurator: I'd probably ask them to 1)relax, 2)shape up a bit, and 3)try again, calmly. Then I'd decide whether they deserve a chance or not...

re: Bug Psychology

Stuart Dootson — Wed, 03 Jun 2009 12:46:47 GMT

I'm sure I remember Code Complete containing a warning against the root cause of all these VT_DATE issues - combining two pieces of data into one data item. The VT_DATE format would be better formulated as a tuple or struct containing (days_offset, offset_in_day), but instead those two parts have been shoehorned into a single double, leading to the mistaken assumptions about how arithmetic works with a VT_DATE because its representation is a familiar type.

re: Bug Psychology

Ben — Wed, 03 Jun 2009 14:01:28 GMT

Off topic, but any news of Wes Dyer? Very quiet on his blog...

Wes drops by the C# language design committee meeting every now and then but I haven't heard much from him either lately. He seemed to be very well when last I saw him though. -- Eric

re: Bug Psychology

Avi Harush — Wed, 03 Jun 2009 16:49:01 GMT

Great post. I always thought that a large IF is 90% a result of a bad design.

re: Bug Psychology

Steve Owens — Wed, 03 Jun 2009 18:43:49 GMT

I really like this line:

I ask myself "how was the person who wrote the buggy code fooled into thinking it was correct?"

When you comes across things you wrote that are clearly not working right, especially when someone else is looking over your shoulder, it's not always easy to admit you goofed. (OTOH, it does seem to be rather easy to point out that someone else goofed.)

No matter who goofed, this is a good time to start with some assumptions:

- We are all smart people (at least somewhere on the upper end of that continuum)

- We all really try to do the right thing (i.e. not deliberately mis-coding)

The comment from @Denis points out how knee-jerk we become when encountering errant code. When you step back from the quick fix and assume that someone reasonably intelligent was trying their best to do the right thing, you have to say "How did they (I) get fooled?"

When you can stop and do this, you might find out something. It could be a bad spec or the need to be compatible with some legacy feature. Or, it could be they never stopped to analyze the underlying issue, like you are now doing.

Either way, you'll be ahead of the game if you ask the question.

re: Bug Psychology

TheCPUWizard — Wed, 03 Jun 2009 19:21:59 GMT

Of course the Chevy Chase approach to Jane Curtain during Weekend Update on SNL (in the 1970's) is an alternative approach to dealing with peoples mistakes [You should hear some of the names I have called myself].

re: Bug Psychology

Pete Montgomery — Wed, 03 Jun 2009 21:31:19 GMT

if (frob(x) > 0 && blarg(y)) return x – y;

else if (frob(x) < blarg(y) && blah_blah(x) > 0 || blah_de_blah_blah_blah(x,y)) return frob(x) – x + y + 1;

else if…

Ha ha! So true.

re: Bug Psychology

Stefan Wenig — Thu, 04 Jun 2009 00:35:38 GMT

// negative dates like –2.75 mean “go back two days, then forward .75 days”

Sweet. Did you ever consider making VT_DATE turing-complete?

Lol. That almost made me spit-take my Diet Dr. Pepper. -- Eric

re: Bug Psychology

bob — Thu, 04 Jun 2009 10:42:14 GMT

There are bugs for which there are no fixes. Accept it. Software is just a flawed thought process made real. But that doesnt mean all bugs can be fixed. Because underneath the hood of that bug, there are 700 other bugs.

Just try and stop whining about other coders. Fact is software can never ever be bug free. Ever.

Ever.

Бажная психология

Блог Эрика Липперта (перевод) — Thu, 04 Jun 2009 11:12:01 GMT

Исправлять баги трудно. В контексте этой статьи я говорю о достаточно «явных» багах – тех изъянах, которые

re: Bug Psychology

Joren — Thu, 04 Jun 2009 13:34:18 GMT

@bob

Most implementations of Hello World are pretty bug free. It's also perfectly possible to structure your code so that it's provably correct. Read some of Edsger Dijkstra's works if you wish to be convinced of that.

I might be able to agree that sufficiently complex software is astronomically unlikely to be bug free (for a sufficiently vague definition of 'sufficiently complex').

re: Bug Psychology

TheCPUWizard — Thu, 04 Jun 2009 16:58:33 GMT

I have to disagree with Bob's comment of "There are bugs for which there are no fixes".

There is ALWAYS a fic os some type of for any Bug.

As an example, (going back to the mid 1980's) there was one 4GL RDBMS company which provided a new release of their product. Certain functionallity which worked great in the previous version was now crippled. Their response "It is not a bug, it is a feature with a negative performance impact".

Thus the bug was fixed.

re: Bug Psychology

Greg — Thu, 04 Jun 2009 18:02:26 GMT

Essentially, code modification usually can be done to refactor existing code to be simpler, better or more robust. Also, improve the inline comments with notes about the cases handled by the code.

Continual application of this slow 0.01% improvement will turn a large system from a mess into much less of a mess within a year or two. Six Sigma.

re: Bug Psychology

Henry Skoglund — Thu, 04 Jun 2009 23:03:32 GMT

I remember a similar bug from the days of Visual C 4.1 (mid-90s):

We were coding a healthcare system and old patients, born before 12/30/1899, got their happy birthday greetings etc. on the wrong day when we upgraded from VC 4.0 to VC 4.1. I think it was a datediff() flavored function that had the same bug as you mention VBScript had. It got fixed in VC 4.2.

BTW, there are so many facets re time and dates and computers: I remember in the 80's when Microsoft acquired Lattice C and later released their own Microsoft C 5 and later version 6, great products. One of the time functions had a safeguard so that when run on a PC without a hardware clock, it would instead return a date from 1955. And I always wondered if that was Bill Gates birthday...

Rgrds Henry

re: Bug Psychology

Denis — Fri, 05 Jun 2009 03:48:17 GMT

@Steve Owens, I totally agree with your assumptions. What I was trying to point out (not very successfully, a bug to my queue :-) ) is that here we have a management problem that results in a dodgy code. Or a corporate culture problem, if you will.

There are some developers who really are over-sensitive about their code and believe in a sort of Samurai code (as in "code of honour") demanding that whoever let a bug slip should perform a harakiri. But most people are twitchy simply because they are worried that, if they are noticed to have stuffed up a number of times, they will be singled out for the next staff reduction, with all that implies.

The remedy to that, I believe, is to promote a culture of fixing the problem rather than the blame: find out what's stuffed up and fix it. In light of that, the question you propose -- "How did they (I) get fooled?" -- may be rephrased into "How did it get stuffed up?" WHO exactly goofed is less of an issue here, because -- and this is an additional assumption to those you propose -- EVERYONE can, and DOES, get goofed, stuffs up, or whatever is your local dialect expression for it. :-)

A goog team leader/manager should be able to drive home the idea that there is no shame in admitting a mistake and putting your back into fixing it; persisting in your erroneous ways is much, MUCH more pathetic, whether it is done out of misplaced pride, or for political (politi-corporate, I mean) reasons of never, ever, wanting to be seen as someone capable of making a mistake.

And the way to achieve that is to lead by example, I recon...

re: Bug Psychology

Gabe — Sat, 06 Jun 2009 07:20:18 GMT

Grant, as interesting as the story is about how the standard railway gauge is derived from ancient Roman standards, it's purely made-up. http://en.wikipedia.org/wiki/Standard_gauge says why: there were many gauges used in the old days of railroads. Since old railways (often used to deliver coal from mines) were horse-driven, it's not surprising that the gauges were mostly around 5 feet, about the width of two horses. Therefore it shouldn't be surprising that ancient Roman wheel ruts were also about the width of two horses. The similarities are only a coincidence.

The current standard gauge only came about as a convergence of many different standards, not because of a direct lineage to Roman chariots.

re: Bug Psychology

Tanveer Badar — Sat, 06 Jun 2009 10:59:23 GMT

Interesting read. I was going to ask the same question as Faraz asked. :)

Community Convergence XLIX (IL)

Charlie Calvert's Community Blog — Tue, 09 Jun 2009 23:47:58 GMT

Welcome to the 49th edition of Community Convergence. The big excitment of late has been the recent release

re: Bug Psychology

Jim Lyon — Wed, 10 Jun 2009 07:37:10 GMT

My favorite maxim to apply in situations like these is that, by the time you're done, the code should look like the author knew what he was doing from the beginning.

re: Bug Psychology

Rich Kuzsma — Wed, 08 Jul 2009 15:42:56 GMT

Consider the product out there that depends on the original, buggy implementation. Your crisp, clean solution breaks backwards compatibility.

re: Bug Psychology

argatxa — Thu, 03 Sep 2009 15:05:23 GMT

@Denis. when fixing bugs, it is very helpful to know who did it so you know the style of thinking of whoever do it.

Trying to figure out why somebody was doing something on a certain way it's way more difficult if you don't have background info (like "this guy always follows the happy path, be way of uncheked previous errors")

The "How did he/she get fooled on this" is easier to answer then.