Best line of the day

From Kickingbear Blog:

Humans are damn good at picking out important visual information rapidly. We’re good at it because otherwise 6,000 years ago we’d all have been eaten by Dinosaurs.

User-Mode Crash Dumps in Vista

One of the good things coming in Vista SP1:

Collecting User-Mode Crash Dumps

Yeah, I thought it was, um, interesting how you couldn't do that before.

I came across this via the very interesting Crash Dump Analysis blog.

Since my days (and nights (and weekends)) are spent trying to get some measure of stability in heavily multithreaded Windows service written in C++ by people who really weren't as good at C++ as they thought they were, I spend waaaaay more time than I should looking at trace logs and sitting in WinDbg trying to get a machine to fail so I can figure out which of the 9 billion threads it crashed in. That's assuming I don't have deadlocks, or even worse, livelocks.

But I digress... Dmitry Vostokov's blog is interesting, and I'll have to check out his books.

Melodyne Direct Note Access

Very cool technology which lets you deconstruct recordings into constituent notes, each with its own pitch and envelope. It probably works best on music with discrete notes, as opposed to, say, voice, violin, etc. Still, compared to dicing and slicing in ProTools, this is probably an interesting alternative.

Big Dog

This is pretty damn cool:

A Real Freak Out

Jim Kunstler's latest polemic: A Real Freak Out

He needs a good editor, but there are some interesting perspectives here:

The object of the game is to prevent the "assets" of Bear Stearns from going to the auction block, on which they would be discovered to be nearly worthless, which would instantly render all similar assets held by the other big banks to be similarly worthless, and would result in a universal margin call that would pretty much unwind the hallucinated "wealth" acquired the past ten years.

Contrast that with the sage pronouncement from President Mission Accomplished that "In the long run, our economy is going to be fine."

Thanks, Shrub: I feel better already...

Update: Krugman sorta backs up Kunstler on this, although Krugman is less willing to contemplate the failure of the system.

Advantages of coming into work on a Sunday

Other than an increase in the likelihood that you'll finally put up that poster saying "Lack of planning on your part does not constitute an emergency on my part", there actually are some advantages of coming into the office on a Sunday:

• traffic is lighter
• more parking spots are available
• the chance of wasting time in a meeting approaches zero
  
• you acquire a slight feeling of superiority over those who aren't in the office with you (making a virtue out of necessity, in other words)
  
• you have more time to think about updating your résumé
  

Gone, Without A Trace

Ouch.

Two for one

Combining two of my favorite topics - technology and security theater (aka TSA) - we get this little gem.  Enjoy.

You might be extremely frustrated with your job if...

• tasks and priorities are reviewed and reassigned daily (people are treated like interchangeable cogs, in other words)
• you've been told you're the lead but you find out your boss has assigned a major task involving design to someone on your team without bothering to tell you
• you have multiple releases of the same product to different customers with different functionality each week
• you're so awash in fixes and changes and hacks you have to ask the marketing guy "What exactly is it we were supposed to have fixed in this release?"

Waterfalls not considered harmful

With apologies to the late, great Edsger Dijkstra. Image from Wikimedia Commons.


Agile methodologies are all the rage these days, with good reason: they work better in the chaos which characterizes most software development shops.

The classic waterfall model of software development is pilloried as an example of how not to do things, but if you think about it, you'll realize that Agile's key insight is to do small iterations, each of them a waterfall.

Heh. Chew on that a bit, and let's discuss...

You still need requirements, although with Agile, you call them user stories or use cases.

You still need design, although now you can sometimes back into it by doing test-driven development. Sometimes, and only on a small scale. I'd argue that you still need the big picture to do design correctly, and the bigger the picture, the more design you need. Design is a topic for another post, so I'll stop here.

You still need to implement - write code, breathe life into the design, etc. - although with TDD, this is a fortunate side-effect of the process.

You still need to verify the code, but with unit testing frameworks, that's much easier. If you're doing TDD, well, you're already done!

Finally, you still need to maintain code, and this is one place where I think Agile gets it very wrong with their emphasis on face-to-face communication over documentation*, because maintenance without documentation is a nightmare. The Agile folks must write a bunch of throwaway systems... but I digress.

Anyway, I think the point of this post is that new things are often just a way of looking at or using an old thing differently.

* While I'd be the first to admit that technical people frequently send email when they should use the phone or just get up and walk over to someone to talk with them, one thing you have with written communication like email is a searchable record of what was discussed and what (if anything) was decided.