Links of the week

25 May 2011

Here are the links of the week that I found particularly interesting or relevant.

  • Design is what matters, in both gardening and engineering.
  • The IAEA, and all its member governments, knew within weeks that the nuclear reactors at Fukushima had melted down, but they didn't tell the public for another month and a half.
  • LinkedIn (LNKD) is the most expensive stock in the US. If we look at price-to-earnings ratios (P/E), their price assumes they will (eventually) be 162X more profitable than Apple (AAPL), or 129X more profitable than Google (GOOG).
  • Irony abounds: the top 10 'welfare' states are solidly Republican (states that give the federal government less than they get). The top 10 'donor' states are largely Democratic.
  • Greece will eventually restructure (read: default) on their debt. The euro's about to go through hell in a handbasket.
  • If you've never heard of MERS, you should read about it. They 'oversee'¬†half the mortgages in the US. And yet, what they do is likely invalid under settled law. There was a recent court ruling that could make their affairs¬†very interesting.

Meme Monday: I got 99 problems, but disks ain't one

02 May 2011

"I got 99 problems, but a disk ain't one"

Re: Tom LaRock (b / t)

What are nine (9) problems that I have encountered, that have nothing to do with disks?

  1. Query plans based on out of date statistics. Auto-update-stats is useless for large tables. I can insert 35 million rows and auto update stats will not do anything, for a 200 million row table. Then the query optimizer thinks that those rows do not exist.
  2. Using linked servers to move data around. The overhead of MSDTC makes data movement via linked servers an exercise in pain.
  3. Bad table design. GUIDs and nvarchar(50) columns should not be in primary keys if possible. Especially not in composite primary keys. Querying and updating the table afterwards is very slow.
  4. People that use object-to-relational mappers (nHibernate, LINQ, etc) without knowing how to troubleshoot them. Then they blame the DB for poor performance, or for not 'dealing well' with their shiny new tool.
  5. Applications that use the wrong isolation level. Don't use serializable by default.
  6. People who release broken code. Code is broken when it cannot roll back, does not have tests, will never scale, has insufficient error checking, or just plain doesn't parse. If you're running a high-traffic website and using just ASP.NET and a database, you're in trouble. Caching, XML, flat files, MSMQ, SSIS...they all have their place.
  7. Using databases as a hammer.
  8. Insufficient troubleshooting skills. Similar to #4, anyone who has to support production systems must know common troubleshooting techniques. Root cause analysis, tracing errors through different systems, asking what has changed...these are all basic skills that aren't usually taught well.
  9. People who focus on features and never stability.

This is one of my banes. I usually hear a combination of, "We're just making a prototype now, we'll clean it up later" and "Oh, that's already working in production, it doesn't need our attention". Those two excuses, paired together, hide a magnitude of sins. The result can be a shoddy system design held together using hacks, duct tape, and user workarounds.


Kendra Little (b / t) Mike Decuir (b / t) Argenis Fernandez (b / t)