A Few Points Of Interest

A few interesting articles I've found on the web recently:

Advice for those thinking about starting a company.  From someone who did it and came back to the corporate world.  If you want to read more about startups, I suggest you check out Paul Graham.

Joel Spolsky writes about the dangers of teaching Java in schools.  I find his thoughts on this subject similar to mine.  You need to learn the hard languages first, even if you don't plan to use them much.  It's easier to learn Java if you know C++ than to learn C++ if you know Java.  Kinda makes me want to go learn Lisp.

Avi talks about a new method for estimating project costs.  It is intriguing because it takes a middle-ground approach.  It doesn't just guess and move on but it doesn't try to plan for every detail either.  I'm really not a big fan of the "we can understand the project fully and thus know the costs" mentality which has left me often in the WAG department.  This new approach may be a good compromise.

I'm also becoming a fan of memeorandum.  Unlike Del.icio.us and reddit, this one seems to have a pretty high signal to noise ratio.

Experimenting With Scrum Part 2

   It occurs to me that some of those reading this blog will not be familiar with Scrum.  Before I go into any details about what did and didn't work about my experiments, I'll take some time to give a quick overview of the process.  For more information, check out the book or Ken Schwaber's web page.

   In a nutshell, scrum is a workflow methodology for developing software.  It is most often associated with practices such as eXtreme Programming but could really be used with any set of programming proactices.  The basic premise is that work cannot be scheduled far in advance.  Instead, it must be handled in discrete chunks and corrections to the course made regularly.  The tools for this are threefold:  the product backlog, the sprint, and the scrum meeting.

The list of potential features for a product is kept in ranked order in what is called a "product backlog."  This list could contain new features, modifications to features, bug lists, etc.  Everything that needs to be done goes on thsi list. 

Next is the sprint.  This is a defined period of time (the authors suggest 30 days) for work to be done.  During this time, no course corrections will be made.  If there is a new feature to be added, it will be handled in the next sprint.  At the end of a sprint, the features set aside for it should be complete and shippable.  The idea is that the product is ready at the end of each sprint.  By "ready" it is meant, the features are complete, not that every feature is there.  It might not be ready for cursotmer deployment yet.  There will not, however, be partially-implemented features and things checked in that don't work.

Finally there are the scrum meetings.  These are daily meetings of the team.  They should be short.  Each person in the room should basically give a quick status.  "Here is what I did in the last 24 hours.  Here is what I am doing in the next 24 hours.  Here are the items that are blocking me."  The purpose of this meeting is to provide visibility into the progress toward the sprint.  At this meeting, work items may be reassigned to others but new items are not added.

The idea behind Scrum is that software development is not like manufacturing.  It is more like original research.  We don't know how long something will take.  We don't know what roadblocks will be put in our way.  We don't even really know what the end product needs to look like because requirements change so often.  The response to this, rather than hiring 14 people just to maintain your Gantt charts, is to do away with them.  If the environment is always changing, the best response is not to plan better up front but rather to learn to react to those changes.  Scrum is one methodology to do this.

As a test development team working on disparate projects, this model doesn't fit perfectly.  I started with just the scrum meetings.  How that went will be described in my next posts on this subject.

Part 1

Part 3

Making the Media Center Remote Keyboard Work

   When Microsoft released their remote keyboard for Media Center, I was excited.  Here was a wireless keyboard, including mouse and MCE-specific functionality.  As an added benefit, it uses the Media Center IR receiver so you don't have to connect another one.  It seemed to be exactly what I was looking for.  I bought one early but was very disappointed.  While I like the eraser-style mouse on a laptop (it's a shame they are disappearing), this one didn't work right.  It was very difficult to control.  It seemed that I could only get it to move a short distance with each push and it was really hard to center on anything.  Despite my wife's request that I return it, I kept it just for the keyboard part.  Now, I'm glad that I did.  I finally figured out the secret of using the mouse. 

There are two things I found make it a pretty decent mouse.  First, you need to turn down the pointer speed a lot.  This can be done via the Control Panel.  This allows for better control and centering.  Without it, I overshot the buttons a lot.  Second, you have to have the keyboard aimed directly at the IR device.  Anything in between, and it responds terribly.  With a remote or with the keyboard keys, you don't notice because you are usually only sending one command but with the mouse, you are sending a stream of commands.  This seems to make a huge difference.  With a good line of sight, and slow pointer speed, it's pretty useful.  I can even navigate the small buttons found on regular windows applications.

The one thing I still can't figure out is how to get the keyboard to work with my motherboard's BIOS.  I have USB keyboards turned on but no luck.  If anyone has this problem solved, let me know.

Experimenting With Scrum

I recently tried using some parts of scrum with my team at Microsoft.  We're a development team in test and tend to have a lot of small, independent projects rather than one larger integrated one.  To make matters worse, we work with audio and video and there is a lot of specialized knowledge with each project.  It is non-trivial to move one person to another task.  As such, it is hard to implement scrum as described in the canon.  There is no clear feature backlog and there is no obvious way to define the results of a sprint for the group.  I always wanted to try scrum but couldn't come up with a good way to do it.  Over the past month or two, I tried to approaches.  I'll go into more detail about them in future posts but here are the highlights.

We went through two phases of work recently.  One was fixing bugs and the other was working on new applications.  Each has a different work flow.  Fixing bugs is more fungible, short, and discrete.  Working on new applications is more specialized, the work items longer, and it is less obviously discrete.  For each, I had the team meet once a day for 15 minutes to discuss their status.  It worked better in some situations than in others.  When the work items were longer, the meetings often seemed redundant from day to day.  When the work items were short, it felt more natural to meet daily.

Part 2

Part 3

Part 4

Dual Core Media Center Goodness

I recently put together a new Media Center PC.  The old one was running on a Pentium4 1.7 GHz and was becoming too slow for my tastes.  It ran okay but was becoming slow to bring up the guide, etc.  The day following Thanksgiving, I was able to score an AMD Athlon 64 x2 3800+ for a good price and decided it was time to put together the new machine.  Here is what I ended up with:

AMD Athlon 64 x2 3800+

1 GB RAM

NVidia GeForce 6600GT

NForce4 motherboard (ECS A939) - it was free with the processor.

Two analog tuners (one Emuzed and the other Conexant)

Silverstone LC14 case

This isn't the absolute fastest machine on the block but it has some getup and go.  I'd heard rumors that Media Center glitched on the dual-core processors but following the advice of David Fleishman, I installed new HAL drivers and haven't seen any issues.  The machine is definitely snappy.  I don't have it hooked up to an HD TV yet but it should be capable of doing WMV-HD 1080p decode with hardware acceleration through DXVA-WMV.

The case is quite cool.  It's a little tall but it has a nice black color and fits well with other media components.  Unlike some of its competition, it has space for more than 1 internal hard drive.  In fact, it has space for 3 of them.  It also has space for 2 CD/DVD drives.  The drive covers are better than most for HTPC cases.  They are flip-down doors, not stick-on cover plates.  The only downside is that there is no way to have a card reader in the case.  I suppose that is what the other machines on the network are for.

While I'm on the subject, I should mention that I'm using a Home Theater Master remote control.  This brings up an interesting issue.  Media Center doesn't work well with universal remotes out of the box because it has some technology to stop signal double-taps.  The behavior you'll get is that each button will work only once and then you have to hit another button before it will work again.  The solution is to follow the advice of Michael Swanson who outlines a registry setting that will diable this feature and let your universal remote work.

Language Inefficiencies

   I spent some time yesterday trying to learn Perl.  I'd looked at it some a few years back but never had a use for it.  I now have a need to write a tool for our build environment and so, based on what is available, I am required to use Perl.  The first thing I noticed about Perl is that it is very powerful.  The second thing I noticed is that it is really ugly.  There are too many ways to accomplish the same result.  Many new languages suffer from this same fate, only to a lesser extent.  What I want to talk about is keeping a language small and compact.  If there is a way to accomplish a task, please don't invent another one with slightly different syntax just to save a few keystrokes.  C++ is pretty good about this.  Other than the multiple ways to cast, there is not much redundancy in the language.  The namespace is fairly unencumbered by keywords.  Modern languages like C#, Perl, Ruby, and Python, however, seem to burn namespace like it is going out of style.  They invent new keywords and operators that add nothing to the language.  One of my favorite examples comes from C#.  The operator 'as' strikes me as wholly unnecessary.  The following code accomplishes the same result:

CFoo cf = myObj as CFoo;

- and -

CFoo cf;

if (myObj is CFoo) {

   cf = (CFoo) myObj;

}

In both cases, we are checking if myObj is of type CFoo and if so, setting the variable cf to point to it.  Why the need for as?  What does it add to the language? 

Perl is much, much worse.  A glaring example is the 'unless' operator.  Instead of typing if(!foo), you can type unless(foo).  Much better, right?  No.  There are many other redundancies.  && and 'and' do the same thing.  I can choose whether or not to use parentheses around my subroutine calls.  You can put if before or after the code you want executed.  The list could go on almost indefinitely.  The worst part about Perl is that the advocates are proud of all of this redundancy.  Even newer, more compact languages such as Ruby have redundant operators.

Here is my rule for adding a new operator or keyword to a language:  Does this operator give me the ability to do something I couldn't do before?  If yes, consider adding it.  If no, reject it. 

I'm not here to bash Perl or any of the other languages.  They all have their place and are powerful.  They also all have a large following.  However, it seems like they could be even better if they were a bit more careful.  Making something already possible merely syntactically easier has the effect of making the language more complex.  While making something a bit simpler to express, you have made the language harder to learn and to retain in memory.  If only language authors would think a second time before making an addition to their language.  Having hundreds of keywords and multiple ways to do everything makes the language harder, not easier to use.

Blog Meltdown?

   I've noticed a trend recently.  Or, at least I think I have.  I have certainly noticed a few datapoints that look like a trend.  Blog software is failing to scale.  For all the penetration of blogs and the millions of people hosting them, they are starting to fail.  Here are a few examples:  Scoble's comments started failing.  Wil Wheaton found his blog FUBARdN.  Belmont Club got too big for blogspot.  I'm sure there are lots of other examples but those are the few that I've noticed in the past few months.  In each case, the author of the blog had to move to a new location and start again.  This is a painful process for everyone.  Users need to remember the new url, RSS readers need to be redirected, bookmarks updated, and search engines need to realize that the old site isn't the best answer.  As I write this Scoble's new site is #2 on Google, #8 on MSN Search, and #13 on Yahoo.

   Why are these sites failing?  I think there are two contributing factors.  First, the concept of a blog means that it is often run by a normal person.  That means a person without an IT staff to back them up.  Once a database starts corrupting itself, you have a lot of work if you want to fix things.  This might explain WWdN but not Scoble or Belmont Club which both ran on large blogging sites that should, in theory, have had an IT staff behind it.  Perhaps not an IT staff dedicated to that site, but at least one committed to the code in general.  This comes to my second contention:  much of the blog code is poorly written.  I suspect that much of this code was hacked together quickly and wasn't really built for or tested to high stability.  It takes a different sort of code to merely get something working than it does to get something to scale really big.  I think in many ways the web is just starting to learn this.  Many successful websites are still overgrown proofs of concept.  They haven't had the major shaking-out period that something of this scale normally has.

   Are these three sites just anomalies or are they signs of things to come?  I suspect that there are a lot more failing sites waiting in the wings.