Orson Scott Card Talks Firefly

One of my favorite authors is talking about one of my favorite shows.  Orson Scott Card was interviewed by the Firefly Talk netcast.  Card is the author of such books at Ender's Game, Speaker for the Dead,  and Ender's Shadow.  All of which are excellent books and should hit your reading list if you haven't read them already.  He talks about Firefly which was a short-lived Fox series about people living on the uncivilized edges of space and what they have to do to get by. The writing is amazing.  It was followed by a feature-length movie called Serenity.  Check them both out if you haven't already.  You won't regret it.

Part 1

Part 2

Part 3

[Update June 5 - Part 2 link fixed.  Part 3 still not posted.]

[Update June 12 - Part 3 posted.]

List of ReadyBoost Compatible Devices

I've been interested in ReadyBoost for a while now but it's hard to find out which devices will work and which will not.  Performance specs do not provide enough information to tell because often they list speeds in only bursty situations.  Some manufacturers will tell you on the packaging but most don't mention it.  For those, the only way to tell has been to buy the part and try it out.  Even though you might be able to return an incompatible unit, that gets old fast.  I just ran across a cool site which, as of this writing, lists the compatibility of 1109 devices.  Of those, 674 are supposed to be compatible.  You can search by manufacturer or just peruse the list of compatible devices.  Quite a valuable resource.

Note:  I'm not on the ReadyBoost team and have no connection with them.  This is in no way an endorsement of this list or the devices on it by Microsoft.

The AMP Summit

Today I attended the Alliance Music Partnership's AMP Summit.  This was the 2nd annual gathering of audio people from Microsoft and the PC industry.  We met at the Experience Music Project (EMP) here in Seattle.  There were people from all parts of the industry in attendance.  There were those who make audio chips, people who create MIDI hardware, representatives from major OEMs, and those from audio software companies.  Yesterday was a general session with high-level information for everyone.  Today there were breakout sessions for business & marketing, software developers, and hardware developers.  I wandered between the hardware and software tracks.  I saw presentations on MMCSS, User Mode Audio, Audio Endpoints, Pull-Mode Audio, MIDI, etc.  Even though I work in the area, I still learned a lot from the sessions.  It was also a great opportunity to mix with people from the industry.  It was a chance to hear their needs and their concerns.  I will use this information to help shape the planning process for what we do next.  As a bonus, I was able to catch up with several of the friends I made at Project BBQ last summer.

Right, Wrong, and Software Design

This is some advice I gave my team regarding code reviews recently.  There are certainly many ways of doing something that are wrong and we must avoid them.  On the other hand, there is rarely only one way of doing something that is right.  All too often we assume that there is one right answer and that all else is, if not wrong, undesirable.  That is rarely the case.  Better does not necessarily mean more right.  It's too easy to waste time arguing over the ultimate solution when we have a perfectly adequate one in front of us already.  This is true in both programming and design.

When it comes to code reviews, we must clearly point out and reject those things that are wrong.  Into this bucket I throw bugs, coding standards violations, and maintenance issues.  If the code contains a bug--that is it will cause incorrect behavior, crash the app, leak memory, etc.--it must be removed.  It is not acceptable to check in code with known bugs in it.  If the code violates the coding standards, it may not be intrinsically wrong, but it is wrong in this context and should be fixed.  Finally, if the code will cause a maintenance issue like it is obfuscated, doesn't allow for proper indirection, etc., it too must be fixed.  Beyond these three items, anything brought up in a code review should be considered advice but the author of the change has final say.  He is free to reject any advice he desires.

This is true not just of code reviews but of coding in general.  There are often many ways to accomplish a task.  Too often we engineers conflate the way we would do something with the right way of doing something.  This explains some of our ever-present desire to rewrite everything.  This isn't productive though.  If someone writes some code and it accomplishes the task, it is usually mistaken to ask that it be rewritten differently.  Again, if there is a substantial issue with the code, it should be fixed.  However, if there isn't.  If it is just a "this could be even better if..." observation, the author should be under no compulsion to change things.  A smart programmer will listen to the advice of his colleagues and act on it often.  A foolish one will always think he is right.

The same principles apply to design.  The more visible the item you are working on, the more advice you'll get.  It is important to have one cook for each soup.  Designers (both graphical and architectural) should solicit advice from everyone, but only act on the parts they want to.  It is easy to get caught in gridlock.  Person A recommends doing things this way.  Person B recommends doing them that way.  Both have valid points.  Which to choose?  Try this approach:  Is A wrong?  Is B wrong?  If the answer to both questions is no, then the only wrong choice is the non-choice.  Pick one and get on with things.  Don't take forever to decide.

This advice applies as much to the person giving the suggestion as to the person receiving it.  If you tell someone a "better" way of doing things, don't expect that they'll just agree.  Even if your way is objectively better, if their way already solves the problem at hand, let the previous decision stand.  Make your suggestion, but don't push it.  You've said your piece.  Now let the person responsible for the decision make it.  Getting worked up about someone else adopting your better solution will be unpleasant for both parties.

Summer School

I decided to take a class this summer.  It looks to be an interesting one.  It is object oriented design.  I've read the Gang of Four book before, taken the NetObjectives classes on the subject, and used it quite a bit in my programming.  The subject matter won't be new.  It should be a good review.  There are two things I'm looking forward to in it though.  First is that I'll get a chance to learn Smalltalk (well, Squeak).  I've never taken the time to learn it before.  While not really a practical language any more, learning new languages gives one a new perspective on coding--even in other languages.  Learning the one that started all of this object-oriented craze will be fun.  And hey, I'll finally be able to read the Smalltalk examples in Design Patterns.  Second, the class is being taught by Ralph Johnson who is one of the Gang of Four that started the design patterns phenomenon.

What's Wrong With HDMI

Interesting article over at Audioholics covering the subject of HDMI and what's wrong with it.  They bring up the legacy of DVI which has a confusing number of options and doesn't handle distance runs well.

"Most computer displays are mounted at most a few feet away from the CPU, so it didn't seem imperative that DVI work well over distance. This lack of concern for function at a distance, coupled with common use of twisted-pair cable (e.g., CAT 5) in computer interconnection, led to a decision that DVI would be run in twisted-pair cable."

The reason this is a problem is that DVI and thus HDMI is not error correcting and runs really fast.  It also runs in parallel which doesn't work out so well over long distances.  This is a real issue when trying to create a home theater.  The better solution would be something serial like HD-SDI.  The article explains some of the electrical properties of coax versus twisted pair and why this causes problems.  HDMI is based on twisted pair.  There are a lot of electrical issues with this configuration.  Moving to HDMI 1.3 with much higher datarates just exacerbates the problems.

 

DRM's Days Are Numbered

Many people have hoped for the end of DRM'd music ever since the first download services.  When EMI announced that they going to sell unencrypted AAC files via Apple's iTunes Music Store, the first crack appeared in the dike.  Today Amazon is announcing a similar effort.  This time, however, the files are going to be in the MP3 format.  Amazon has EMI on board and "12,000 record labels."  I suspect most of those 12,000 are people you've never heard of.  EMI appears to be the only big fish that has taken the plunge so far.  Can the others be far behind?  Not if this model proves to be of value. 

I've spoken before about the ephemeral nature of computing these days.  Music is one of those things that was easily lost.  If your music store went out of business, you could be at risk of losing all of your purchased music.  The music probably still worked, but only on that machine.  Certainly if something happened, you could never download it again.  If this new direction gains the momentum I hope that it will, this risk could go away.

Does this mean that DRM'd music will disappear completely?  I don't think so.  Having used MTV's Urge service for a few months, I have to say the experience of all-you-can-eat music is quite compelling.  DRM will live on to support this scenario.  Music rental will continue to be distributed with DRM but I suspect that music purchase will continue to move away from it.  I wonder how the video market will react.

The iTunes music is going to be in 192 kbps.  I haven't seen any figures on what the quality of the Amazon stuff will be.

Three Types of CS Programs

In my mind there are three different types of programs you might find when looking for CS or CS-related degrees.  When choosing a school to attend, it is important to understand what their focus is going to be.  If what you want out of a program doesn't align with what they are teaching, you'll run the risk of dissatisfaction.  I'll call the three school Computer Science (CS) , Software Craftsmanship (SC), and Information Technology (IT).

The first type of school is probably the oldest.  Most degrees will be offered with this title although some are offered as Computer Engineering.  The focus of these programs is to prepare you for research.  They'll cover a lot of the theory behind computing (predicate algebra, complexity theory, computational theory, etc.) and the practical classes will often be more survey than in depth practice.  Many times you'll find these schools don't focus much on the quality of the coding you are required to do.

The second type is the hardest to distinguish.  I use the term Software Craftsmanship instead of Software Engineering because schools like Seattle University offer Software Engineering degrees that are similar to, but not quite the same as what I have in mind.  That program appears to be more about software development systems management than programming.  This school is teaching you to go into the industry.  They teach what is needed to be a systems programmer.  The focus will be on knowledge that can be applied.  This means a little less math and a little more programming.  This sort of program doesn't ignore things like algorithm complexity (because that is useful), but perhaps does so in a manner that is more programming-centric rather than math-centric.  Operating systems, compilers, graphics, etc. are all classes you should expect to take.  One school which set out explicitly to be of this sort is Northface University (now called Neumont).

The third type of program I call an IT degree.  This is most often offered by community colleges, commuter colleges (like City University), and low-end state colleges.  It's not exclusive to these sort of schools, however.  These programs are designed to be practical, but in a different way than the software craftsmanship.  The focus is on those skills needed to work in an IT shop.  That means, the sort of place where you implement back-end line of business software and/or support it.  They teach a lot of SQL, Web development, networking, etc.  Usually these schools will teach operating systems and algorithms, but not at a very deep level.

It is my assessment that most schools teach either CS or IT and that a very large number of students take the wrong sort.  No that many students start into school and want to do research in computer science.  Most want to apply it.  If you want to work at a software development shop, the best fit is a school designed to teach software craftsmanship.  Unfortunately, not many schools offer this.  Why is this the case?  I suspect it has to do with the roots of computer science.  When computers were new, the first programs offered in academia were offered in math departments.  This is responsible for the math-bias of most CS programs.  Professors are rewarded for publishing research, not for implementing working programs.  This means that they teach what they study.  I.e. they teach for research because that is their focus.

Most people graduating with a CS degree are not really ready to contribute to business.  They don't understand testing.  They aren't very good at debugging.  They have never been required to write maintainable code nor to maintain someone else's code.  There's a steep learning curve in your first job.  It doesn't have to be this way.  We could spend more time teaching people the art of systems software creation and less time teaching them how to prove that their for loop will exit.

I tend to think more programs should offer a software craftsmanship focus because that is what most people attending the schools will be doing when they graduate.  I'm sure there are many who disagree though.  If you are one of them, let me know what I'm failing to take into account.

Great Discussion of HD Photo

HD-Photo is a new image format coming from Microsoft.  It is intended as a replacement for JPG.  Bill Crow, the program manager for HD Photo, took the time to hang out with the guys from This Week in Media.  The netcast covers a lot of interesting ground including what is wrong with RAW, JPG, and TIFF and why we might want yet another format.  The new format uses floating point values instead of integers which allows for high dynamic range.  That means it can represent parts of an image that are whiter than white or blacker than black.  Unlike some other formats, however, it is highly compressed so the files aren't too large.  I was skeptical that we needed yet another format but after listening to the arguments, I'm convinced this is a good thing.  I'll be watching closely to see how well the industry adopts this format.

Done With Class!

This morning at 8:00 I took the final for my Computer Security class.  It feels good to have that behind me.  I enjoy taking classes (which is good as I have 4 more left) but they push out so many other things from life.  There are books I've wanted to read for a while but haven't really been able to.  Now I will.

Video Acceleration By The Numbers

Here's an interesting article from AnandTech talking about the new GeForce 8600's video acceleration features.  It features H.264 acceleration.  The article analyzes the performance win from doing acceleration in hardware.  It also gives some statistics on VC-1 (standardized WMV) acceleration.  It compares the CPU usage with NVidia, ATI, and no acceleration.  The results are, shall we say, stunning.  While this shouldn't be your only input for buying a video card, if you want to play video, these data points are certainly important.

While I'm on the subject, here is an interesting post from one of my team's program managers on choosing display cards for video in Vista.