Sloppy coding always shows, even for Microsoft

Looks like EFYtimes can't find any high-quality programmers.

On August 19th, that site is apparently experiencing the slashdot effect. I went there based on a slashdot article, and I expect the site's problems are because a lot of other people are doing the same.

If you go to the link later, it's likely that the problem will have gone away. Here's what I saw:


Microsoft OLE DB Provider for ODBC Drivers error '80004005'

[Microsoft][ODBC SQL Server Driver][SQL Server]Transaction (Process ID 100) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

/efytimes/lefthome.asp, line 193


There are probably a lot of people who will blame this on the crappiness of Microsoft products, I want to be a pillar of sanity in this sea of mindless MS-bashing.

The problem is not Microsoft's, it's the fault of the low-quality coders who created this site.

I've run up against this time and again when I was doing freelance consulting. It's extremely difficult to differentiate yourself from all the other idiots out there who claim they can write code. But this kind of thing is what makes the difference. Here's the three things the programmers of the EFYtimes.com site did wrong:

1. Transaction deadlocks are caused by sloppy SQL, and/or a programmer who doesn't fully conceptualize multi-user activity. Usually, entry-level programmers don't have the experience to write truly multi-user database applications. The problem is that they're locking rows to liberally and the database server is given commands that it can't execute. This isn't a Microsoft problem, any SQL server that supports concurrent access will throw a similar error if the application programmer gives it locking instructions that are impossible to achieve.
2. The application was never tested properly. Many organizations don't understand the need for effective load-testing. Here's your lesson. Problems that don't occur at low volume may cripple your application at high volume. If the developers had properly tested the application at high load, they would have seen this and fixed it before the site went live. On a related note, I've talked to development teams who were having this problem and were unable to understand what they did wrong. It's part of the reason I got out of the consulting business.
3. The final mistake falls into the category of calling the programmers dumbasses. Why did they not trap SQL errors and present a rational message to the visitor? Who (besides me) understands what an SQL deadlock is? The page should read, "The site is experience difficulties, please try back later." The fact that their SQL is showing is an embarrassment to the site, and to the people who coded it. Apparently, the programmers don't care if they look like dumbasses.

There are lessons to be learned from this.

If you're hiring programmers, realize that you get what you pay for, if you want to hire some low cost, inexperienced folks, this is the kind of crap you'll get: a site that falls on its head just when it really should be showing itself off.

If you're a programmer, don't write sloppy SQL. And catch errors and redirect to some error page or something. I can only imagine what kind of shit is going to roll down the hill to the lazy one who made this mistake. Secondly, demand enough testing to find problems like this before they embarrass your employer.

It's a tough world out there. Don't think you can get away with doing half-assed work. I don't appreciate this kind of thing get blamed on Microsoft. Misdirecting the blame doesn't do anyone any good.