Resolved: To Blog More in 2010

As the year closes I look back and see that my blogging really dropped off this past year.  I intend to try to blog more over this upcoming year.  My position at work has changed from a lead to a manager and that gives me a whole new perspective on things and a lot of new ideas to blog about. 

I hope your 2009 went well and that 2010 goes even better.  For those who are hurting in this bad economy, hang in there.  The sun always rises even if the night is long.  Don't give up improving your skills.  It will pay off in the long term.

A Taste of Stack Overflow DevDays

If you missed Stack Overflow DevDays, there is some audio from it available on Stack Overflow Podcast #71.  I wish there was a longer version of this.  It’s only about 1/2 hour of outtakes from the conference, but it is still interesting to hear.  These snippets are followed by a long discussion with some of the speakers.  The conversation rambles and the audio quality is poor so feel free to stop listening after the conference outtakes.

Design Patterns Are Not Outdated

A comment left on my answer to a question over on Stack Overflow has me a little worked up.  I've seen this meme come out of programmers more and more and it just doesn't seem accurate.  The statement goes something like this, "Design Patterns were only useful because C++ (or Java) was so broken."  The implication is thus that design patterns belong in the dustbin of history now that we have moved on to more enlightened languages like Python or Ruby.  In this particular instance the commentor was talking about the strategy pattern.  His (?) assertion was that the need for the strategy pattern is not present in a language with first class functions.  My response is three-fold.  First off, this argument is historically ignorant.  The design patterns came as much from Smalltalk as from C++.  Second, it is not strictly true.  First class functions alone don't obviate the need for the strategy pattern.  Finally, providing an alternative implementation does not make the first implementation bad.

The argument that design patterns generally are due to flaws in C++/Java are historically innaccurate.  Design patterns (like much of modern programming) originated in the Smalltalk community.  Smalltalk is dynamic.  It has first-class functions.  Most of the flaws pointed to in C++ which "modern" languages solve did not exist in Smalltalk.  The patterns, then, have value independent of that flaws and the accused language.  For instance, the Strategy pattern is covered not just in the Gang of Four (where it happens to have a C++ example), but also in the Design Patterns Smalltalk Companion which points out that it is used in Smalltalk in the MVC framework at the heart of Smalltalk's GUI.  The controller is a strategy pattern.  It is also used ImageRenderer and a few other examples.

First class functions do not, by themselves, obviate the need for a strategy pattern.  This is more a nit than a real argument, but it remains true nonetheless.  To say a language has first class functions means merely that functions can be passed as data types.  It does not necessitate that the language implements closures.  Closures are a way of capturing the context of the function.  They can be used to retain state between calls to a particular function instance.  Without closures, there is no state.  Without state, many of the strategy pattern uses fail.  Consider for a moment using a strategy pattern to encapsulate encryption algorithms.  Without closures (or objects), you would have to pass the encryption key to the function every time it was used.  This is possible, but not terribly elegant.

The existence of an alternate implementation does not make the original implementation any less useful.  The fact that I can get much of the power of OO out of first class functions and closures does not mean OO is now of no value.  There are advantages to both techniques.  Empirically there does appear to be power in OO that is not captured (easily) by purely functional languages.  Most successful functional (or psuedo-functional) languages have adopted OO features eventually.  See Python, Ruby, Common Lisp, Scala, etc.  All added or have object-oriented features.  Let us return to the example of the strategy pattern.  Is its utility obviated by the use of first class functions plus closures?  In many cases it is.  Certainly it could be in the encryption example.  On the other hand, strategies are often more complex than mere functions can express.  The controller in MVC is a strategy.  In anything but a toy application, the controller will consist of multiple functions.  Sure, one could create these functions with the same closure and thus share state, but is that really a superior model?  I would argue that it is not.  In this case it would seem a less clear mechanism because the fact that the functions are tied together is less discoverable.  OO languages and functional languages each do things differently.  Things that are easy in one are more difficult in the other.  Neither is superior in all respects.

It should be noted that when I say "design patterns" above I am referring to it in the common sense of the object-oriented programming design patterns made popular by the Gang of Four book.  In a more general sense, each language has its own set of patterns and these can also be thought of as design patterns.  Some of the OO patterns are specific to OO languages and the need doesn't translate to functional languages.  Others are more "in the large" and likely translate well to all languages trying to solve big problems.  It is my claim, however, that most of the GoF patterns will be useful in any OO language.  They are not artifacts of particular implementations such as C++ or Java.

Is there really a benefit in lossless audio formats?

Lossless codecs are all the rage amongst those who aspire to be audiophiles.  Whether it is ripping CDs in a format like FLAC or WMA Lossless or listening the TrueHD track on Bluray movies, there are those who swear by it.   Most audio formats like MP3, AAC, and WMA are lossy formats.  They compress the audio by throwing away parts that humans theoretically cannot hear.  This is called “perceptual coding.”  Lossless codecs don’t throw away any information but instead compress more like Zip.  Lossless formats require a lot more space to store and a lot more bandwidth to transmit.  Are they worth it?  Can people really hear the difference?

TrustedReviews says no.  They go so far as to suggest than anything over 192kpbs MP3 is virtually impossible to differentiate.  “[A] few people in the last six months or so - people who take their audio gear seriously and have spent thousands of pounds on Hi-Fi equipment - have admitted privately to us that 256kbps MP3 is easily good enough for serious listening, and that they struggle to hear much difference over 192kbps MP3 in many situations.”  They conducted some A/B listening tests to see if ordinary people could perceive a difference.  The results did not support the extra expense and size of lossless formats.  In fact, most people couldn’t even differentiate between the 192kbps MP3s and a FLAC encoded version of the same songs.  The test wasn’t scientific, but there’s a pretty good chance it matches what those reading this blog will experience. 

Considering that most people listen to their music in noisy environments, on suboptimal speakers, or on tiny headphones from an MP3 player like the Zune, the chances they will ever be able to perceive the differences in audio are quickly diminishing. 

The short of it:  don’t waste the space ripping everything to lossless unless you plan to do a lot of transcoding in the future.  Don’t go out of your way to get a TrueHD movie setup.  AC3 is going to be just fine.

A Review of a Kindle

Six months ago I purchased a Kindle 2.  I originally bought the Kindle to make travelling easier.  I tend to carry a lot of books with me when I take a trip and those books get heavy.  With the Kindle, I could carry just this one device instead of 5 books.  The Kindle didn’t disappoint.  It weighs less than the typical paperback book.  It fits nicely in my Scottevest jacket.  I typically have about 80 books on mine at any given time giving me plenty of potential reading material.  If that isn’t enough, there is the Kindle store with some 360,000 books.

The Kindle satisfied the purpose I bought it for, but has exceeded my expectations.  Not only do I use the Kindle when travelling, but it has become my preferred reading device.  The screen is a delight to read on.  The contrast may not be quite what it is on a real book, but it is plenty good.  The screen on the Kindle is much more comfortable to read on than the screen on a phone or a laptop.  There is no refresh rate and no backlighting.  This results in a significant reduction in eye fatigue.  I can read on the Kindle as easily and as long as I can read a paper book.

In addition to being a great place to read, there are several features of the Kindle that make it my preferred reading tool.  The first is the built-in dictionary and the second is the ease of taking notes.  When reading a dead tree book, if I come across a word that I don’t know, I will usually guess at the meaning from the context and move along.  With the Kindle, I can just move the cursor over the word in question and get a definition at the bottom of the screen.  In this way I am able to understand the nuances of the text and expand my vocabulary.  The Kindle is also a great place to take notes.  Want to add a note?  Just start typing using the integrated keyboard.  Want to highlight some text?  Move the cursor to the start, press down, move to the end, press down again.  The notes and highlighted areas are collected in a text file that you can upload to your computer.  They are also available on http://kindle.amazon.com/.  The notes will follow the book to other devices (like the new Windows software).

So what isn’t to like?  The Kindle is an excellent book-reading platform.  It is a single-task device.  It is great at what it does and not good at anything else.  It has a built-in web browser, but it is the sort of thing you would only want to use in case of emergencies.  It does not render pages well, is difficult to navigate, and is very slow.  For instance, when composing an e-mail via either hotmail or gmail, it writes the letter, deletes it, then writes it again.  It is very easy to get well ahead of the cursor even on the limited keyboard.

The Kindle supports MP3 playback, but not in any useful fashion.  You cannot see the songs.  You cannot select the songs.  You can skip to the next song, but that is all.  There is no shuffle.  Playback happens in the order the songs were put on the Kindle.  To say this feature is limited is an understatement.

The Kindle only reads its own formats.  It can read variations of the mobipocket format but cannot read pdf, epub (the standard ebook format for everyone else), or even the encrypted mobipocket format found for free at many libraries.  This choice perplexes me.

The note-taking is simple and works well, but it is capped.  If you highlight too much of a book, the highlights will continue, but the material will not end up in the notes file.  This wouldn’t be quite so bad if you were warned but you aren’t.  Instead you find out later when you go to the notes file and see a warning instead of the highlighted text.

Perhaps the most disappointing part is the lack of software innovation going on.  As someone accustomed to the rate of innovation on other devices, it is disappointing to see no new firmware or features being pushed.  The hardware platform is stable, but why not improve the mp3 playback?  Why not add new formats?  Why not add support for tags or folders?

A few questions and answers:

How is the battery life?  It is amazing.  With the wireless left on, it will last several days.  With the wireless off (and there is no reason to leave it on), it will last weeks.

Is it economical?  No.  If you buy a Kindle, don’t buy it to save money on books.  Sure, they are a little cheaper than the hardcover, but maybe 10%.  At $259 for a Kindle 2, it is going to take a long time to make up the difference.  If you watch, there are many free books available which can help, but it is not a cheap device. 

Are most books available?  That depends what sort of books you like to read.  I have found that a large percentage of what I read is available.  I still run into many books I want that are not available, but I’m not running out of books on it either.

How about technical books?  Surprisingly, it is pretty good.  I have read a few programming books on it including Programming Clojure and Javascript:  The Good Parts.  It renders them just fine.  Where it falls down is in the random access.  I don’t recommend using it for reference material.

How does it compare to the Nook?  I don’t know.  I haven’t used the Nook.  It appears to have superior hardware in most respects, but the book pricing is much worse.  If I were making the choice today, I would still choose the Kindle.  The Nook does appear to be giving it a run for its money though.  Strong competition is probably what the Kindle needed.

Do you recommend the Kindle?  Yes.  Highly.  If you like to read, get one. 

StackOverflow DevDays

I spent the day at Benaroya Hall for the 1st (annual?) StackOverflow DevDays conference.  Overall eight speakers took the stage on topics from .Net MVC to Python to the Google App Engine.  The room appears to hold just over 500 people and it was filled to capacity with programmers.  There were some vendors in attendance including Amazon.com, Fog Creek Software, and someone showing off HexBugs.

The day started off with a short video titled Scrumms which was a funny spoof on life at Fog Creek and the StackOverflow podcast.  It was quite entertaining.  I hope they release it on the web after the conferences complete in a few weeks.

Joel Spolsky was the first speaker.  I always enjoy reading and listening to him.  This speech was not a disappointment.  He was as entertaining as ever.  The subject matter under discussion was that of design elegance.  He began by pointing out that software often gives the user too much choice.  Often times it interrupts the user’s work flow to ask a question most users are unprepared to answer.  Other times there are options pages with myriad options which no one could know enough to actually use.  What is a “trusted user” on GMail anyway?  He cited a study where one store put out a lot of varieties of jam (24?) for people to try.  Many did, but substantially fewer actually purchased than when the same store put out only a half dozen varieties.  People are intimidated when given too much choice.  Joel recommended the book, The Paradox of Choice.  He then went on to talk about the simplicity offered by companies such as 37 Signals whose products do only one thing, but do it well.  He argued that this isn’t the solution.  Customers will demand more features and to grow, a company must grow its feature set.  More sales leads to more features.  Choice must be offered then, but how to do it in a way that doesn’t alienate the customer?  The solution Joel offered up was to make sure the choices support what the user is doing.  The users should be modeled and choices aligned along the path of their behavior.

Joel was followed by Scott Hanselman who gave an overview of the ASP.Net MVC framework.  This is a web framework built on top of the ASP.Net framework, but which exposes much more direct control to the programmer.  For instance, they now have direct control of their URL’s (yeah!).  Scott was an entertaining speaker although I think he was a bit too self-deprecating about Microsoft.  He spent most of the talk showing the audience various features in existing and upcoming Visual Studio products which make ASP.Net MVC programming easy.

Next up was Rory Blyth talking about iPhone development.  He was an engaging speaker who obviously knows a lot about what he is doing.  I had never looked at iPhone or Objective C development before.  I can’t say I’m terribly impressed.  The tools like adequate, but aren’t as good as Visual Studio or even Eclipse.  Objective C looks like a mishmash of C and Smalltalk.  Rory described learning to develop for the iPhone as the Stockholm Syndrome where you eventually come to love your oppressor.  The iPhone is an attractive target to develop for from a business perspective (maybe), but the SDK doesn’t appear to be the reason people are flocking to it.  One highlight at the end was when Rory showed Novell’s MonoTouch which allows for C# development targeting the iPhone.  This looks like a slick environment even if it is a little pricey.

Following Rory came Joel again with a sales pitch for FogBugs 7.  I have to say I was impressed with the empirical scheduling.  There is a new plugin called Kiln for code reviews which looks alright, but I think I prefer the UI from Malevich better.  For instance, the comments didn’t appear inline with the text when they were being made.  They did later when the submitter saw them though so perhaps I just missed something as Joel blazed through the UI.  If I were a startup, I would definitely consider using FogBugz to handle my planning and bug tracking needs.

Lunch was catered by Wolfgang Puck and was reasonably good consider it was a conference and the whole thing only cost $99.  They divided up the tables into discussion topics (great idea!).  I went to a table about programming languages, but others included agile methods, startups, and a few I forgot.

The first speaker after lunch was Cody Lindley from Ning who was talking about jQuery.  jQuery has been on my list of topics to learn about, but never made it to the top of said list.  It’s fascinating technology, especially considering I just read Crockford’s Javascript:  The Good Parts recently and got a feel for the language as it was meant to be used.  For those that don’t know, jQuery is the most popular Javascript framework right now.  It runs on 35% of all Javascript pages on the web and 21% of all web pages of any kind.  It’s primary use is to make manipulating the DOM (the page structure) much easier.  Boiled down it lets a programmer easily select some portion of the page and apply an effect to it.  In implementation, it appears to be a Javascript function that wraps up a collection of page elements into a class which then provides methods for manipulating the set.  Cody used jsbin.com for his demo which appears to be an online javascript testing and debugging tool.  It looks very nice.

Daniel Racha from Nokia was next up to talk about Qt (pronounced "cute" not "Q-T").  This is a cross-platform UI toolkit and development platform recently purchased by Nokia.  It is also the basis of the K Desktop Environment (KDE) for Linux and is where Webkit originated.  Webkit is the rendering engine that powers Safari and Chrome.  Nokia’s plan is to use Qt as the basis for its phone app development story.  The technology and the tools are both mature and highly capable.  Daniel did a good job selling the merits of Nokia’s tool chain.  Considering the toolkit supports 6 platforms right now (Windows, Mac, Linux, plus several phone OS’s), I can see how this might be the way for cross-phone applications to be written.  Daniel also mentioned the Nokia N900 which apparently is completely open source to the point where end users could upload their own OS.  I can foresee 3rd party variants like those created for the Linksys routers.  This could be an interesting challenge to Apple’s iPhone strategy.

Ted Leung from Sun came to talk about Python.  This is another language I haven’t had time to learn yet.  His slides were terribly hard to read (purple on black—seriously?), but the content was good.  He gave a quick overview of the language basics and then talked about more advanced features like destructuring, generators (simple continuations), decorators, and extensions.  Python has definitely taken a lot from the world of functional programming.

Dan Sanderson was next up and gave an introduction to the Google App Engine.  It looks like an interesting way to build out scalable web sites.  This is the competitor to Amazon’s S3 and Microsoft’s Azure.  It supports the Python and Java virtual machines and so sites can be implemented in Python, Java, or any language that targets the JVM (Clojure, Scala, JRuby, etc.).  With that kind of support it would seem an app programmed to it would be capable of being moved, but that would not be the case.  The app engine is a very different sandbox to play in.  The database is non-relational and doesn’t support SQL (or at least fully SQL), the filesystem is different, there is no direct network access.  In short, once an app is written to the App Engine, it won’t easily run anywhere else.  The environment looks intriguing, but you are putting your company’s fate into Google’s hands.

The day ended with Steve Seitz from the University of Washington talking about some of the advances in 3D image extrapolation.  Steve is behind much of the technology that became PhotoSynth.  Steve’s talk was light on programming content but high on “Wow!” factor.  This was a great way to end the day.  I’m not sure my mind could have taken another heavy talk.  The stuff Steve showed us was mind blowing.  They are able to take regular photographs, process them, and recreate the 3D scene.  Not only that, but newer technology allows for a walkthrough of the site and even full texturing.  You can see it here.  The best is this one:

Overall the day was well spent.  I got to learn about a lot of cool new technologies and renew my excitement for programming.  Now I just have to pick one and find the time to learn it.  If the event takes place again next year, I definitely intend on going.  Thanks to Joel Spolsky and the folks at Carsonified for putting on such a great conference.

For more, find other reviews on Meta.Stackoverflow or watch the Twitter stream.

 

Forging a Team Identity

For a group of coworkers to have a chance of becoming a team, they must share a common sense of purpose or identity.  Dave Logan in Tribal Leadership calls this a “Noble Cause.”  On small teams this often comes naturally.  Everyone is working on the same project or related set of features.  As teams become larger, their goals become more dissimilar and team identity becomes harder to forge.  It is up to the leader to forge this team identity.

Having a unifying cause (whether noble or not) is important to get the most out of a team.  If people are all working toward a common goal, they will make the right compromises to do what is best for the team as a whole.  If there is no unifying cause, people will be working to optimize locally which is usually at odds with global optimization.  Each person will be trying their hardest, but if they are pulling is different directions, some of their effort will cancel out the effort of others.  Having a unifying cause does not guarantee that people work in concert, but it is certainly a prerequisite.

How does one go about finding a unifying cause?  First look at the obvious candidates.  If the whole team is working on a particular product or feature area, just use that.  In my past I have unified teams around the concept of working on audio in Windows or on being the video team.  Sometimes there is no single feature to focus on.  In my last position I had 3 teams working for me.  Each had a distinct area to work on.  We were all part of the Windows organization, but we were such a small part that we couldn’t take that as our identity.  Each team even had its own identity, but as a group of leads, we didn’t.  What Joe was working on didn’t relate much to what Jane was working on.  I was convicted by Tribal Leadership and Good to Great that we needed a point of unification, but there wasn’t a product we has in common.  It was time to forge an identity rather than find one.

The unifying principal I chose was becoming better managers together.  This is something we all had in common, being managers, and something we could help each other with.  Even if the technologies we were working on didn’t form a conceptual whole, our positions did.  Toward this end we made sure to have a lot of discussions about managing people.  We would discuss situations and how to handle them.  We started a weekly “book club” where we would read a chapter of a book each week and discuss it in our leads meeting (more on this in a future post).  It worked well.  The team began to gel work work together.  People began forming triad relationships rather than being dyadic.  That is, they started helping each other rather than merely reporting everything to me.

It is important that a team, whether it be a team of ICs all working on the same feature or a group of leads reporting to a manager, have some common identity.  This in turns requires a goal or a unifying principal.  If there are no obvious candidates to be found, identity should be forged from something less obvious.  In the second case, it is easy to operate without a unifying goal, but things will run less smoothly.  Be intentional about ensuring each team has a common identity.