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.

iPhone SDK

Photo shamelessly stolen from the Omni Mouth blog.

Like I need another reason to get an iPhone...

All the goodness of Cocoa and Objective-C: nice.

Of course, I'll need to move to Xcode 3, which means I need to upgrade (finally!) to Leopard, which means now I have yet another reason to get a 17" MacBook Pro.

Heh.

Our government at work

A Wave of the Watch List, and Speech Disappears

Lovely. The ignorance and stupidity just gets deeper. I'm sure the idiot who made the decision to shut down the domains had a flag pin on his lapel, so that makes everything okay, right?

Is it 2009 yet?

New words for today

Siooma (rather crude, found via FSJ)

Rickrolling (thanks to John Moltz)

Oh, and if you like lolcats and the Mac, check out Daring Furball, a most excellent reworking of the always interesting Daring Fireball.

I can has Mac indeed...

Domestic terrorism?

While I understand the loathing which led ELF to torch some 4,000+ square foot "green" homes in Seattle, I don't agree with their actions.

However, are they really terrorists? Vandals, yes. Criminals, absolutely, and I believe in the rule of law.

However, terrorists they're not, and calling them terrorists smacks of fascism.

The Richard Test

The Joel Test is now 7.5 years old (!) and while it's a good first start, I've decided to fork my own version to suit my own preferences. This test is to be used once you've done some research on the company and found out as much as possible about the position. You should be able to ask many of these questions during the phone screen, and you should also let everyone involved know that you'll be asking more than a few questions.

Some notes about prescreening a position
If the job position is vague or contradictory, be wary: they make things up on the fly, and if you're okay with that, this test is definitely not for you. Have fun in Hacks and Deathmarches 101, though. It's right down the hall, inside the room with all the pizza boxes outside...

If the company has a lot of openings relative to the number of employees, be wary: they either have a problem keeping people or they're growing too fast.

If they're looking for junior developers and don't mention mentoring, be wary: they're cheap. There's nothing wrong with being thrifty, but cheap means they think they can get more for less. You don't want to work for a cheap company.

If they talk too much about how everyone socializes after work, be wary: they're a cult.

If the company is a software company and the person running the company has never written code for a living, be wary: while I've seen this work okay (as in my last job), it means that software people will be second-class citizens and management will never really understand schedules. Conversely, most technical people are not suited for management, so like everything, there are tradeoffs. A good software development manager can insulate you from much of the nonsense, but they're rare.

A corollary: if the software development manager has never written code for a living, look elsewhere. While they might have a rudimentary ability to cut code, they don't really understand the issues.

And now, on to the test.

The Richard Test

1. How do you manage version control?

Good answers are git, subversion, Perforce, ClearCase, etc.

Best answers include some mention of configuration management.

Bad answers are SourceSafe, CVS, and "What's version control?"


2. How do you build your products?

Good answers are CruiseControl, CruiseControl.NET, etc.

Best answers include a fully automated system for pushing builds to a repository, website, etc.

Bad answers are "We tell Jeb over there to send the build off his machine."


3. How do you manage issues and defects?

Good answers are FogBugz, JIRA, TestTrack, etc.

Better answers include some mention of a process which includes automated testing (when possible) for each fix. Give them a gold star if they have a way for customers to report bugs directly into the issue tracking system.

Bad answers are Excel, Post-Its, emails in a folder, etc.


4. How do you manage requirements?

Good answers include some discussion of features and some discussion of ranking them.

Better answers include some mention of traceability matrices, Steve McConnell's book, etc.

Bad answers are "We have the marketing people write them, and we just implement them."


5. How do you manage schedules?

Good answers are mentions of Agile practices, so long as they don't mention XP. Look up how successful the big project all the XP guys like to talk about really turned out to be. For that matter, if having two programmers "pair code" is good, why not have 3 or 4? Heck, have the whole team pass around a wireless keyboard in front of a projector and see how much code you get written. There's a reason John Carmack is one of my heroes...

Better answers include evidence-based scheduling (hey, I'm still a huge fan of Joel, even if I have the hubris to update his test).

Bad answers are "We try to figure out what we can deliver to the customer without having them sue us." I've heard this at one of my jobs. Seriously.


6. What best practices for software development do you encourage?

What I'm looking for here is some discussion of coding and design standards, test-driven development, design reviews, code coverage, etc.

Better answers include some mention of Code Complete or similar books.

Bad answers are "What do you mean by best practices?"


7. Describe your software development process.

This is a bit of a setup. What you're really looking for is whether they have enough of a process to describe it coherently without sounding like they're just thinking about it for the first time.

Better answers should mention that the process exists in some printable form.

Bad answers are at both ends of the bell curve: either they have no process and make everything up on the fly, or they have too much process and you have to fill out a form to make a change to the code. We're looking for a happy medium here.

Lots - and I mean LOTS - of companies are still at the left end of the bell curve, unfortunately.


8. What development tools would I get when I start?

Good answers are a new machine with the standard Microsoft development stack.

Better answers add a second machine, dual monitors, an MSDN subscription, and - depending on the specifics of your work - some additional tools like Visual Assist X, TOAD, etc.

Bad answers are a crufty old laptop that a couple of other people have used. Again, this is what I got on the first day at one of my jobs.


9. What are your offices like?

Good answers are individual offices with doors. Note that I said individual office.

Better answers are decent seating (Herman Miller, for example) and good desks with lots of work area and storage.

Bad answers are cubicles or shared offices. If they mention bullpens or team rooms, run AWAY!


10. What do you do to support professional development?

Good answers include reimbursing for books and tuition.

Better answers include sending employees to one conference or training session per year, or maybe letting them spend one week each year working on a pet project (learning Ruby on Rails or Python, for example: something technical).

Bad answers include asking "What do you mean by professional development?"


Extra credit
Some other things to ask about:

• telecommuting
• flex time
• core hours
  
• geographic location of the team (outsourcing is another sign that the company is cheap).