Explaining GitHub Part 2

If you just tuned in, I’m attempting to explain Git and GitHub to the layman. The previous post was all about Git. This one focuses on what GitHub actually does.

Part 2: GitHub

Okay, now we can move on to GitHub. Unlike writing a paper, software developers rarely write code all by themselves in a closet. Well, some do… but most of us collaborate on our software projects. GitHub provides a meeting place for software developers to collaborate around code and the different versions of that code. It stretches the analogy, but imagine that your paper with all the different snapshots you took along the way was available for other people not just to read, but to derive new papers from. You would always be credited as the original author, but everyone can create derivative works and if someone added a really nice abstract you could pull just that change back into your version of the paper. GitHub acts like a digital room where everyone hangs out to share their projects, ideas, and most importantly their code. The same way that Facebook provides a medium for people to hang out digitally and share status, photos, notes, etc –GitHub provides a medium for programmers to share code.

Code is a very abstract notion to people who don’t program for a living, and this is where I think the idea of writing a paper as an analogy for writing code is very helpful. Just as you could have written your paper in Spanish or French or English, code can be written in any number of languages. The primary purpose of code is to communicate something to a computer. You can think of it like writing an instruction manual. In 3rd grade, I remember, we did an activity where we had to explicitly write out the instructions for making a peanut butter and jelly sandwich. The teacher then took our written instructions and followed them to a tee. If you wrote “Take two pieces of bread”, she would literally tear off two very small pieces of bread to start making the sandwich. If you didn’t explain how to open the jelly jar, there would be no jelly on your sandwich. If you didn’t explicitly say that the jelly and peanut butter sides of the bread should be touching in the middle, you would get a sandwich with jelly and peanut butter on the outside. This is what it is like when you have to communicate with a computer. At the lowest level, computers are really dumb; they can only do what they are told, so your instructions (code) must tell the machine exactly what you want it to do.

As you can probably imagine, writing all this code can get very unwieldy. Not only because of the sheer amount of code that it takes to develop a complex system like the Android operating system, but because that code is written by a large number of programmers (think lots of people editing the same paper all at once). This is where GitHub really shines. GitHub provides the ability for developers to publish and share code, solicit collaboration from other programmers, gain reputation in the community and discover/contribute to other code projects of interest. In many ways it is a realization of the original intent of the internet. To throw out yet another metaphor, GitHub creates a framework for the evolutionary improvement of software in real time. Like the evolution of species, software is allowed to mutate and change over time creating new variants, symbiotic relationships (sometimes even parasitic ones!), and a dazzling array of constructs and programs. GitHub is like primordial soup in which all these software projects are interacting, growing and changing. And instead of eons, this all happens at the speed of the interwebs.

If you want to learn more about GitHub, you know where to go.

If things are still fuzzy, then all you need to know is that we run a web site…. And we sell these cute little creatures that are a cross between a cat and an octopus…

Explaining GitHub

GitHub is well beyond being just another startup, but I still find myself explaining over and over again what it is that GitHub actually does. My brother posted this link on Facebook the other day with a comment that he still has no idea what we do, but has so far surmised that it has “something to do with a cat and an octopus”.

So here, presented in two parts, is the crash course for the layman:

Part 1: Git

We have to start with Git. Git and GitHub are two different things. Git is a version control system. You don’t need to know anything about it other than it is amazing.

Okay, maybe I’ll tell you a little more than that. If you have ever typed a paper into a computer (or written one by hand) you have probably used a low fidelity form of version control. Say you are working on a big paper and at certain points you want to save off a version or draft. You might do this for many reasons. Maybe it is an important paper and you want to put a copy somewhere else safe. Maybe you add a `01` to the filename and later a `02` and so on (or you might use today’s date `ImportantPaper_4_13_2011.txt`). Maybe you need to turn in a draft or pass a draft off for editing. These activities are all analogous to creating a snapshot of what your paper looks like at a certain point in time and saving it off. Another good example of why having snapshots is important is if you are going to completely re-write your conclusion. Having a saved version of your old conclusion lets you go back to it at any time to see what you wrote or even to revert back because your new conclusion turned out to be a bad idea.

Software developers are usually focused on code instead of papers, but they have the same problems. You need to be able to quickly and easily take snapshots of the current state of your code base (along with some comments about that revision) and have the ability to come back to that point in history at any time. You might also want to compare the current state of your code with any previous state. Programmers call the solution to this problem version control. Just as you could write your paper in any number of document editing systems (Word, Pages, text files, Quark, LaTeX, etc) there are many different version control systems. Git is one of those systems. Developers write programs in a variety of computer languages and these programs are sort of like big papers, but vastly more complex. Having the ability to take snapshots frequently and travel back in history to see how a code file changed over time is an essential activity.

If you are really interested in learning more about Git you can download and learn about it here. I would also highly recommend my friend Scott Chacon’s book Pro Git.

If you have stuck around just for the Octocats, then I suggest you head over to the octodex until part 2 comes out.

7 series

Here is why I’m excited about Windows phone 7 series, which i’m just going to call 7 series from now on because it hurts me to type the entire name.

Finally something new. I wasn’t sure that MS would take the leap and literally throw away backwards compatibility with Windows Mobile. But they did and I’m fully on board with this decision. I’ve spent the past 4 years developing applications and frameworks for Windows Mobile and while Microsoft’s development tools are first class, the actual OS is one of the most frustrating pieces of software I have ever dealt with. It is always entertaining to watch first time mobile developers try to make sense of WM and do something simple like visit a web site. I think the smart and agile companies are going to quickly move on from the old Windows Mobile platform and see significant increases in the rate at which they can develop/deploy mobile solutions. I think the end users are going to require less training, and make fewer support calls. It is a rare day when Microsoft is seen as a leader in something like UI look-and-feel and everything I’ve seen so far about the 7 series interface has been fantastic in that arena.

Commercial grade devices in the enterprise. My prediction is that 7 series will bring on further movement of commercial grade devices into the enterprise. Right now, most of our customers use special ruggedized devices that are expensive, but very difficult to break and have embedded RFID/barcode readers, etc.  However, the decision makers in these companies are now coming up on year 2 or 3 of using things like the iPhone as their own personal computing device and expectations for mobile computing have grown considerably. From the durability perspective it is hard to rationalize a $2500 device when you can buy 5 or 6 commercial grade devices for the same price and just replace them when they break. In light of all this, we are starting to see more and more people request comercial grades devices for their enterprise applications and I think this trend is only going to accelerate. There will continue to be room for Windows Mobile, but the mobile companies that can deliver 7 series apps and phones are going to lead us into the next phase of mobile computing.

Development story. My guess as to the development story goes back to pre-PDC a year ago where there were small hints of something new in the mobile world at MS and then a complete blacklisting of everything mobile at PDC. At that time we were being told something new was in the pipeline but we weren’t privy to any details. Our own research brought us to the conclusion that the next platform would probably be Windows CE 6 or 7 based with an entirely new UI layer requiring XNA based development. XNA is managed code, but with a completely different model for rendering the UI that lends itself to game development much better than the existing WinForms message pump. This is what i would guess 7 series development is going to be like. I’m also hearing that there is a mobile version of silverlight as part of the development story. I think this will be a great option for many applications but it doesn’t solve the central issues in enterprise app development which usually entails large amounts of data, some of which must be cached locally on the device. As it stands right now, silver light doesn’t have an answer for this. And besides, the text rendering is awful like the rest of WPF. Every time I start down the WPF/silverlight route I end up frustrated with how unreadable text is and how unacceptable to any customer the migraine inducing application I might create would be.

mfLY! will live on. mfLY! is our internal MVC framework for developing rich mobile applications and because of the MVC pattern we will have only a small amount of work to do to create new views, but the rest of our applications should stay exactly the same. To be perfectly honest, this is a blessing, b/c the old Windows Mobile UI is painful at best. We made the decision 2 years ago to fully commit to the managed code story and while there are still some challenges we have come up with a highly  performant and compelling development platform that will easily move up to the 7 series platform. Good news all around here.

Sleep and dreams and developer double time

First of all, if you are not listening to radiolab, I am actively getting smarter than you. And yes, I know radio is an old technology – I listen via podcast.

I’ve been mulling over this post for the course of the long weekend after listening to a very old radiolab show on the topic of sleep. The entire show is fascinating but there are a couple parts in particular that resonated very clearly with all this talk lately about movement and loving your tools. Have you ever had the experience where you focus so intently on learning something to the point where you aren’t even really making progress anymore? And then, after a night of sleep you wake up and suddenly you can play that rift on the guitar or that problem you were trying to solve so hard is suddenly clear? This happens to me all the time and I’ve joked that I actually do some of my best problem solving in my sleep. Well Jad and Robert present some interesting theories around this behavior which is very widely recognized. It seems that the first couple hours of sleep are largely devoted to replaying the events of the day and a process not unlike erosion takes place where the master volume knob is turned down, lowering the noise of all your memories and experiences. What they found, however, is that things like practicing the guitar for hours and hours stick prominently above the rest of the background noise and although these erosive forces literally wash across your brain causing you to remember everything a little less clearly; at the end of the night the really important stuff now stands out clearly above everything else. That mountain of your focused guitar playing memory still got eroded away, but since it was so much higher than the rest of your memories from the day it actually ends up standing out clearer when  you wake up.  Not only do things that you focus on have this permanence in comparison to everything else, but basically anything that invokes some sort of emotional response. You emotions are like sticky notes to the brain signalling the importance of certain memories.

The next part of sleeping involves mixes the days experiences (after the erosive process has finished) with all your other memories. This is where things get weird and interesting and where in many cases people have claim to invent things in their sleep. It seems that you brain just kinda randomly starts combining things together – mixing and matching experiences with memories and senses.

What really stood out to me about all this was what it means for developers who love their jobs and their tools vs. developers that don’t. Between Joel and Brooks and many others, the general consensus is that all software developers are not created equal and that the good ones are better by orders of magnitude in terms of productivity and quality. I’m thinking a  lot of that comes down to passion and emotional response to what you do on a daily basis. Sure, raw talent probably has something to do with it too, but when developers are passionate about what they do and in an environment where they love the tools they use and the software they are creating then you are basically getting double time from them.

Do your developers dream in code? Are you aware how valuable the ones that do are to your business?

Some ideas about the how

So the first question I got from my friend Sean in response to my post Movement was ‘How?’ As in, how do you iterate quickly? How do you prevent the freeze frame?

Two ways: automation and love your tools.

In order to move with agility in software development, you must have any and every mundane and reoccurring task automated. This means understanding every step that needs to be taken to go from writing some code to seeing that particular piece of functionality running live in the real world. That path might include building source, running tests, interacting with version control, building installers, deploying the application, running more tests, rolling back the deployment and so on and so forth. All the little pieces it takes to connect your code to live functionality in the hands of the end user. Iterating quickly also means you must understand all the keyboard shortcuts and secret tricks of your tools. Those seconds wasted formatting your code in VS instead of pressing Ctrl-K-D matter. You must also have  a version control system that allows you to prototype and iterate quickly without fear or mal consequences. This is very much an evolutionary/natural selection-like process where you need to be able to rapidly try out ideas and designs, keeping the ones that work and leaving behind the ones that don’t.

Secondly, in order to move quickly in software development you absolutely have to love your tools. I’m talking about a real emotional connection here. When you love your tools you want to know everything about them. How do I do this faster? Is there an option for that? Wouldn’t it be great if it did this? How do I extend my tools to do this? Maybe you’ve built some of your own tools. Maybe you love Visual Studio. Maybe you love Emacs. I’ve seen developers who use nothing but a text editor and a shell (plus a whole array of scripts and custom utilities for making things happen) so the actual specifics of the tools doesn’t really matter. What matters is that you love them and learn the ins and outs of them.  Right now, I think ReSharper is brilliant; Dropbox makes me smile daily; and Git and Github are revolutionizing version control. Your tools are everything from the physical hardware of your PC to your OS to where you write your code, to where you application gets deployed and how you managed everything in between.

Finally, your ability is iterate is directly tied to the speed at which your feedback loop can communicate. The quality and speed of communication through the network of people involved determines how quickly you can put your tools to use to connect feedback, ideas, innovations and real working software.

Movement

Have you ever noticed how grotesque people look in videos when you press pause. The most beautiful move star looks odd and unattractive when frozen mid facial expression. To be alive requires that you change and move. Art, film, music, culture, fashion, ideas all rely on this flux. Yet change and growth are difficult – it is a constant fight against entropy. Sometimes it’s joyful, sometime it’s painful.

Great software requires change and growth as well. Sometimes that means more features. Sometimes that means less. Sometimes it means taking the same ideas and implementing them in a new technology or applying them to a different space. Sometimes that means starting from scratch. Sometimes that means evolving what you already have. As people and culture change, so must software change to keep pace. And to support this entropy fighting back and forth our software must be designed in a way that allows iteration. Rapid prototypical development creates a natural selection pipeline for the truly ingenious ideas to be brought forth. Interestingly, but not surprisingly this idea hints that along that line of evolutionary change are 10,000 ideas that failed for one reason or another. This is the reason why you must have a way to iterate quickly.

And if your software isn’t growing (or isn’t changing fast enough) then you become like those actors frozen in a single frame or like a poorly streamed video that starts and stops: showing a static image every few seconds. And unlike the eons afforded to natural selection your time is a little bit more limited.

Build on top of what you’ve got

I think one of the most challenging things about building software to meet real business needs is the sheer number of choices you have in how to go about realizing a particular business goal. Here is just a small list of the things you have to worry about:

Are you going to build it as a web application? a rich client? or maybe both.

If you’re building a web app:

What browsers will you support? IE? Firefox? Safari? Opera? Will you support mobile devices? Which ones? Will you have a dedicated mobile version of your site? What technology will you build your site with? .NET? Java? Ruby? What about the many tool kits ontop of those core technologies? Googles Web Kit? ASP.NET? ASP.NET MVC Framework? Ruby on Rail? What languages are you going to use? What kind of servers will it run on? Windows? Mac? Linux? In the cloud? Hosted? Database technology? How will you handled off line devices?

If you’re building a rich client app:

Will you support mobile devices? Which ones? Windows Mobile? Palm? Android? iPhone? Will you support full desktop devices? Which ones? Windows? Mac? Linux? Which versions and flavors? Windows XP? Windows Vista? Windows 7? Windows Server 2003? Server 2008? Server 2008 R2? All the versions of OS X 10? Which of the many flavors of Linux? Is there a server side component for the rich client to sync with? Where is it running? In the cloud? On a server you control? Hosted? What OS? What database? Oracle? MySQL? SQL Server? Virtualization? What technology is it built with? .NET? Java?

The list goes on and own – it’s like a choose your own adventure book. And then you start mixing and matching technologies. And each of these technologies is moving forward with new versions – sometimes that path forward is easy, other times it isn’t. But the technology that you choose really does matter. And the tools that help you use that technology really matter too. They are difference between success and failure. But the real kicker is that your choice also has to match with the culture of the organization you are working in/with – as crazy as that sounds. People’s emotional response to different technology can make or break a project. It’s the difference between someone staying up all night to work around some bizarre issue in a technology they believe in and love vs. throwing their hands up and saying ‘see, we should have used blah instead, this will never work’.

We as developer’s aren’t any help either. The grass is always greener on the other side of the fence. There’s always something new to try. There’s always the next great tool, framework, language, abstractions, etc. We love trying new stuff, new versions, new architectures. In part, these desires are essential to our field, but we need to be challenged in our decisions more often.

If you look at our sales slides that describe the mNOW! Mobile Framework, they are littered with a dizzying array of technologies – each with their own dependencies, acronyms, and versions. In fact, if you dived into each one of those technologies you’d find another massive layer of things that that technology is built on, and so on. In part, this is the very essence of software abstraction. It’s the magic black box. The thing I’m talking about though, is the sheer number of black boxes and how you mix and match and decide between them to achieve your goals.

Let’s look at all the layers in a simple mobile application built on top of the mNOW! Mobile Framework. For the device-side application we support almost all Windows Mobile and Windows operating systems, we build apps with mfLY!, which is built on the .NET CF and .NET Frameworks respectively. We use log4net as our device-side logging framework. For smart devices, we often use Resco controls and on the full Windows devices we use DevExpress. Many applications use bar code readers or RFID scanners and the associated hardware and software stacks. Our applications store data locally using SQL CE and SQL Express. We use ADO.NET, LINQ to SQL, the EF and our own custom OR/M layer built specifically for the Compact Framework. All of our applications sync data using WCF web services and/or Sync Services and/or replication and/or some internal sync technologies. We often use some of the functionality in the OpenNETCF framework. On the server and integration side we support most Windows Server operating systems (Server 2003, 2008, 2008 R2). We use SQL Server (05 and 08) extensively. Our server side software builds on .NET 3.5 SP1 and leverages WCF and WF. We have an integration engine that runs as a Windows services, and a variety of ASP.NET Web sites and WCF Web services hosted in IIS (6 & 7). We use many of the P&P enterprise application blocks. We use LINQ to SQL, EF and our own DAL. We have rich client administrative tools built using .NET, CAB, the enterprise library, DevExpress, Northwoods, Dundas that also leverage WCF web services. Our installers leverage WiX for the client and server applications and cabwiz for the devices. To keep track of all this stuff we have an internal Wiki where we keep track of the versions of all these tools that we are using and general guidance/ best practices for using them. As I get to the end of this I’m realizing that this doesn’t even touch the development tools that we use to create this software! The mess above is just for the end runtime application.

And at a certain point, you come to realize that the technology that you are using has issue XYZ or doesn’t support ABC. This is the moment of Joel’s leaky abstraction where you can no longer go on using this piece of the system as a black box, because it’s abstraction has failed you in some way. All of a sudden you need to understand what is inside the black box and in some cases you have to dig into all the black boxes inside the leaking black box to really understand the issue. Where I get caught up here is that at this point that those alternative black boxes start to look really shiny. I’m talking about the other components or technologies available that address the same problem. I’m positive that the black box alternative to the one I’m using doesn’t have issue XYZ and I want so badly to ditch my black box and use another one.

Part of Vista’s failure was that the abstraction leaked and all of a sudden we were all painfully aware of low level stuff like drivers, and the complexity of one OS having to handle a infinite number of hardware variations. I was personally never let down by Vista, and while there were many pieces that felt unpolished or rushed out the door, the OS was a positive step forward. It was shocking to the Windows community because one of the hallmarks of Windows has been the amazing backward compatibility support for almost everything in the ecosystem. And while Vista maintain 90% of this, the 10% that it didn’t was painful.

Apple on the other hand is in the business of leaky abstractions and has somehow managed to turn it into a sales pitch. They educate their users on the details of things like their processor architectures, and then as they change architectures the sales pitch changes to why the new is better than the old. They play right into that ‘other shiny black box’ syndrome that I was talking about above so everyone thinks ‘yeah, you are right, PPC is dead, Intel rocks’. They even do this with major versions of their OS (think 9 to 10). I recently upgraded my laptop to 10.6 but my PPC desktop is forever stuck at 10.5 because the backward compatibility buck stops there for PPC machines. Apple literally sets out to create a new black box every few years so that we will all think our current black box no longer cuts it. Now don’t get me wrong, Microsoft does this too, but in moving from Windows XP to Vista just about all of my software transferred completely and functioned as expected. In moving from OS 9 to 10, just about every software manufacture had to re-write their software. With 10.6, Apple is not so subtly encouraging everyone to re-write their software again to be 64 bit.

So where does that leave you as a software developer trying to solve real problems? Now, if the only applications you are creating are mobile fart apps for the iTunes app store, then you probably don’t care about this post. But if you are creating real line of business applications then not only do the black boxes that you choose matter, but your willingness to stick with them even when they leak matters even more. You have to keep building on top of what you’ve already got. It’s the only way to create lasting business value. There are some very good reasons for upgrading software or moving to a different vendor. I think every developer should create a list of what these acceptable reasons are. Certain features may be critical to creating business value. Security is certainly a reason to stay up to date. Bug fixes that are getting in the way of meeting your requirements. It would be a good activity to enumerate this list of good reasons to upgrade your black and a separate list of good reasons to ditch your current black box and use another. Otherwise, I think the grass is green enough on your side of the fence.

The Code Reviews Keep Coming…

Well, we are coming to the end of our second week of daily code reviews and I thought I’d share some of my thoughts and general experiences.

First off, lessons learned. I realized very quickly the first week that despite my diligently creating a table of who was reviewing who – I failed to take into account people that were out of the office or on site with customers. The rearrangement wasn’t difficult, it would just be nice to think of those things ahead of time. The other piece that I realized quickly is that there are days where you don’t actually write any code or you are legitimately tied up in other things that don’t allow you to be reviewed. In this area, I think the team has been fantastic in rolling with the punches. I didn’t want these code reviews to be an annoying hoop that you have to jump through and that means if it doesn’t work out on a certain day, that is your call to make. I even found myself not participating at least one day a week.

The benefits so far? I’ve loved hearing reviews going on in the background of the office. It seems like all sorts of things are getting discussed that nobody ever talked about before. I actually really enjoy being a code reviewer and the best part about our system is that I get to see all the cool things that everyone else is up to. Reviewing Sean this week brought up some interesting discussions about things like what happens when you throw an exception from a finally block (hint: nothing good) and I liked his replacable user interaction service so much that I stole the code for a project I’m working on. We have some very talented and creative developers working here and the daily reviews are such a great chance to see what kinds of neat things everyone has created to solve their respective problems. Since we are all creating very similar mobile applications in the enterprise space, there is often great crossover and a good idea that Cliff has can be immediately relavant to what I’m working on and vice versa. With out the excuse of a code review, you may never know what the other developers on another project are up to. The other big benefit I’m seeing is that the daily reviews are acting as grease in the wheels of communication. In a very grass roots way we are solidifying our processes and best practices. We are working towards standardizing on simple things like naming conventions, project structures, release practices, versioning, installer technologies etc… These things aren’t being created by me sittting behind Word for a week creating something that immediately becomes a dead document, but instead are being born and refined out of our daily communication and current best understanding of how to develop exceptional software.

Daily Code Reviews

We all know that code reviews are important right? But how often do you actually have someone review your code? How often are you responsible for reviewing code? How often do you actually take the time to read code that someone else has written and understand what it’s doing? I’ll be the first to admit that it’s been a while since someone reviewed my code. I usually seek out peer review only when things aren’t working, or if I want to show off some cool new language feature or pattern that I just learned. Otherwise, code reviews are hard to come by. They require that you disrupt someone else from their job to come look at your code. And believe me, it’s scary having someone look at your code. I look at code I wrote 6 months ago and think ‘What was this idiot doing? – oh wait, that’s me!’ I think that code we write can become very personal, yet one of the best ways to improve as a developer is to have to show that code to someone else and explain what you were trying to accomplish and why you made the decisions you did. Sometimes the hardest problems can melt away just by explaining that problem out loud to someone else. I can’t tell you how many times I’ve called a co-worker over to my desk to rant about some issue or bug that I’m trying to solve and before they even get a chance to speak or fully understand the issue I’ll have come up with the answer. Just the act of saying it aloud and explaining the problem to someone else is enough.

We are rolling out a new line of mobile products here at Blue Dot and I was pulled into one of these projects to review code and help get stuff out the door at the last minute. The more I thought about it over the week, I wished that we’d been doing detailed reviews over the course of the development instead of waiting until the end of the project. But how do you enable this? How often should we review code? Once a project? Once a sprint? Once a day? What’s keeping people from seeking out peer review? Who should be doing the reviewing? Who should get reviewed?

In response to all these questions, this is what we came up with: Our dev team is going to strive for daily, cross project, peer code reviews. Let me explain some of the key factors to this. First, I’d like to see reviews happen on a daily basis. Every day I’m responsible for reviewing someone elses code and someone is responsible for reviewing my code. I don’t think these need to be massive code reviews and if they are truly happening on a daily basis there is only so much code you can write between them. Some days there maybe little or nothing to review. The key to reviews happening daily is that I want to catch things quickly and get developers comfortable with the idea of reviewing and being reviewed. This should create a small feedback loop so that if on Monday one of the action items out of your code review is to not hide exceptions, by Tuesday’s review (which you know is coming) – you’re going to be very aware of not making that mistake. Second, these reviews are done cross project. What this means is that the code you are reviewing is not necessarily from a project that you are actively working on. At Blue Dot we have a pretty small development staff, but we work on a LOT of projects at once – often with only 1 or 2 developers on a single project. The idea of cross project reviews is that you get to see what everyone else is working on and this will setup and environment of cross project pollination. If you are working on project A and need to implement WCF streaming, the cross project review system is going to enable the appropriate communication for you to discover that project B has already solved this problem and can just reuse and/or improve upon their solution. Even with our small development team it is amazing how often we solve the same problems over and over again because people just don’t know or have time to know the details of other projects. Finally, code reviews are to be done by peers and on a daily basis you get to act both as a reviewer and as a reviewee.  Even if you aren’t a senior developer being a code reviewer gives you the chance to see new code, ask questions, raise concerns and maybe even point out something you learned earlier when your code was reviewed. For more experienced developers this is a great chance to provide mentoring in a structure environment, talk through advanced issues and features, see what common problems are across our code base, and begin to understand where more training is needed or where better guidance should be provided. One last thing that I think is key to all this is having some sort of formal structure of being specifically assigned to review a particular persons code. We are going to start by rotating our assignments weekly – so for one week you will have the same person reviewing you code (and you will in turn review a different individual all week). The reason this is important is because it removes the barrier of collaborating with someone you potentially don’t know well or are afraid of disrupting. It’s also  nice to have a week’s worth of continuity to see improvements and check up on specific weak points.

I’m excited to see where this goes, and plan to post progress, results and the evolution of this process on this blog. I don’t have or want to have any specific rewards tied to developers participating in this as I think the motivation to write better code and build better applications is enough. If nothing else, I’ll bet the people that really take advantage of this are going to quickly rise to the top in terms of knowledge, code quality and success in their individual  projects. Stay tuned!

Hubristic UIs

I stumbled across Wolfram Alpha and hubristic user interfaces by Mencius Moldbug today via a link from Joel. It is well worth a read and a good starting point for a Friday post.

What are the different types of user interfaces that we interact with on a daily basis? Do you really want your user interfaces to be more intelligent? Or would you rather supply the intelligence yourself and use the interface as a tool to achive some goal of your own. Mencuis has some interesting thoughts on the subject of interfaces with hubris tendencies and dives into specific examples like the Apple Newton’s handwritting recognition vs. Palm’s Graffiti. I love this idea:

Therefore, if you are building a control interface, ie a tool, the prudent way to proceed is to (a) assume your users will need to learn to use your tool, (b) make it as easy as possible to learn the tool, and (c) make the tool as effective as possible once it is learned.

Palm did just this with their original version of Graffiti and while I myself have never been a Palm users, my wife raves about her first Palm pilots and how well the Graffiti featureworked for input. As Mencuis states, the key is that as a user you had to learn how to use the tool and align your mental model to the graffiti input model – after that, the distraction of the tool fell away and you were simply able to get what you needed to get done done. However, in the later versions of Palm’s devices, they started changing Graffiti to make it ‘better’ at recognizing natural handwriting. And it was a total failure. As my wife would tell you, all of a sudden instead of being able to learn what specific stylus strokes resulted in english characters, you were expected just to write and the Palm would interpret what you meant. It didn’t work! Not only that, it was no longer predictable. The mental model you had formed for how Graffiti interpreted stylus input was no longer valid and because of the new ‘intelligent’ system it was very difficult to form a new mental model.

My real interest here, though is to look at other software we interact with and see how it is helping/hurting us as users trying to get something done. So what software do I use on a daily basis?

• Windows 7
  • Chrome
  • Internet Explorer
  • Explorer
  • Messenger
  • Google Talk
  • Word
  • Power Point
  • OneNote
  • Outlook
  • Paint.NET
  • Calculator
  • Adobe Reader
  • Command Line
  • Visual Studio 2008
  • Reflector
  • Resharper
  • DevExpress
  • Dropbox
  • GhostDoc
  • Infralutions
  • SQL Server
  • Plaxo
  • VMWare
  • Remote Desktop
• OS X Lepoard
  • iTunes
  • iPhoto
  • XCode
  • Terminal
  • Commandline tools: gcc, makefiles, etc
  • Preview
  • Firefox
  • Safari
  • VMWare Fusion
  • Mozy
  • Spaces
  • Dropbox
  • Finder
  • Google Sketchup
  • Remote Desktop
  • Cisco VPN
  • Time Machine
  • Hulu Desktop
  • vi
• iPhone OS 3.0
  • Mail
  • Calender
  • iPod
  • Facebook
  • SMS
  • Remote
  • Weather
  • Photos
  • Weather
  • Pandora
  • Maps
• Browser Applications
  • WordPress
  • Gmail
  • Google Reader
  • Sharepoint
  • Team City
  • FogBugz
  • Stack Overflow
  • Facebook
  • Hulu
  • Netflix instant watch

And that’s not really an exhaustive list. The final challenge is making some sort of sense out of all of this. Here are the high level categories I see related to human-user interface interaction:

Gateway User Interfaces

Web browsers and OSs are good examples for this category. The UI is a means to access other UIs. A good Gateway UI  fades into the background allowing the user to move on to what they originally intended to acomplish. Despite the marketing that goes into informing the public about OS and browser features, the reality is that people use these things as a means to get to something else. In fact, the best features in these interfaces are tools for better managing, organizing, and accessing other content, applications and interfaces. If you are focused on or required to configure/mess with a gateway UI, then it has failed it’s job. A good example of this is the driver chaos in Windows Vista. People didn’t care about all the under the hood enhancements in Vista, they were pissed that the OS no longer acted as a gateway to their existing devices (cameras, printers, etc).

Command Line User Interfaces

There is a whole slew of tools that fall under this category, but the general pattern is a steep learning curve with lots of power, efficiencies and payback for those who tackle the challenge. While not a strong example of a graphic user interface, there still is a very real user interface element. These UIs are very much tools in the real definition of the word and require time and training to understand and make full use of. The only issue here is a lack of accessibility and discoverability for the average user. You have to have a problem to solve that is worth the time investment in understanding how to use the tool.

Human Bi-directional real time connectivity User Interfaces

These are instant messaging, collaboration, real time meeting user interfaces that provide the ability for humans not in the same physical location to communicate. They share some commonalities with the gateway interfaces in that their real purpose is to get out of the way and let real humans effectively talk to each other. At the same time, something is almost always lost along the way as face-to-face human communication is much more than a voice, or a text message, or a video image, or a power point or a screen sharing session. There is still great value here from a cost and distributed team standpoint and the benefit of spreading ideas globally at the speed of light (or at least the speed of the internet).

Human Bi-directional right time connectivity User Interfaces

Email is a big one here (although many people like to use their email for instant messenging). Forums are another good example. The idea is that there is a real conversation going on between people and groups of people, but it isn’t instantaneous real-time like a face to face conversation. Each side has a chance to regroup and carefully format a response. Spelling and grammar matter to a larger degree and thoughts can be filtered in a way that they aren’t in real conversation. This has it’s advantages and disadvantages, but the user interfaces are a reality in our lives.

Human Single-directional connectivity User Interfaces

These are presentation user interfaces like Power Point, where there is generally one person on a soap box, communicating something specific to a larger group of people. They are often combined with some of the bi-directional user interfaces, but I feel like this is a real category on it’s own. There is great value and real need to have this kind of 1-direction communication. TV is an interface like this, as is a lot of the internet.

Informational Presentation/Aggregation User Interfaces

I’m thinking about things like Adobe Reader, Preview or Google Reader for this category. These user interfaces are just the messenger for bringing content to the user’s eyes. They don’t choose the content or care what the content is. In a way, they are also gateway user interfaces in that the user is just using them to get to something else.

Scratch Pad User Interfaces

Here I’m talking about OneNote and Notepad and Todo lists and anything else that is used simply as you would a sticky note or a pad of paper. The information here is transitive. Sometimes it seems very important at the moment and later means nothing. Other times you find yourself reaching for it over again over again, wishing that your brain was better at remember that sort of thing (like your WEP key or your wife’s SSN). These are interesting interfaces because there is often so much information that could potentially go into them and it is challenging to keep straight between computers, phones, home, work. The scary thing for me is that I have a dozen of these systems spread out over multiple computers and locations that may or may not be in sync with each other. Sometime it’s better just to have a physical notepad or journal that you can carry around with you.

Machine Communication (Control or Tools) User Interfaces

This is just a funny name for a category of interface that allow you to communicate with computers and create more interfaces – i.e: programming in it’s many forms. This could be Visual Studio or an Excel spreadsheet, COBOL or Objective-C. There are so many tools, languages, platforms and user interfaces that it isn’t worth making a list. They key is that you are up a meta layer and now you are using a tool to make another tool (which might end up making another tool…).

Infrastructure, Meta Organization User Interfaces

I see these as background interfaces for the most part. A VPN client is a good example. Or Plaxo. Or Mozy. There is usually a 1 time setup associated with these interfaces and then the user expects them to just continue doing their job.

Personal Entertainment User Interfaces

iTunes, Netflix instant watch, Solitaire etc. These are interfaces that we use to entertain ourselves. In the end, they share a common goal with the gateway interfaces in that they are a pass through to other content that we wish to enjoy. The best user interfaces in this category get out of the way and let the content take center stage. The worst ones get confused and think that we as the user care about the Personal Entertainment User Interface. We don’t. And the worst of all is that with competing entertainment user interface vendors, we as consumer’s inadvertantly get locked into silos where the content we own only works with certain interfaces.

Hubristic User Interfaces

Mencuis argues that Wolfram Alpha is a hubristic user interface, but I say that maybe all interfaces have some elements of hubris in them and that is what we want to understand and avoid. The reality is that we don’t really want our computer systems to be intelligent in the same way we are intelligent as human beings. Instead we want them to complement and augment our intelligence and allow us to reach new understandings and innovations. We have enough trouble as a species communicating among ourselves and getting things done, why would we want to  increase the communication barrier with machines too? (Granted your goal might be to create machine intelligence, but that is another subject entirely) In each of the categories above, the user interfaces that succeed and meet user needs are the ones that get out of the way and do the best possible job of letting the user achieve his/her goals. I think this is part of the success with the bare bones interface of Google’s search engine and the subtle text based ads. Their user interface design acknowledges that you are there to look for something. You are not there with the hopes of finding a good ad to click on.  If what you are looking for happens to relate to what someone else is offering, then many times an ad is actually helpful and everyone is happy. If not, then you can move on with your real task of getting whatever you set out to do done. Many other search engines fail because they don’t understand this principle and their hubris affect’s their market share. The reason why boot up time matters on a PC is because all the end user cares about is watching a movie on Hulu or changing their Facebook status. They don’t care about all the other fancy system you are loading up for them to manage windows and display fancy graphics and index your file system, etc. I think it is worth looking hard at the hubris in the user interfaces we are designing and getting rid of it. The challenge is that hubris often sells well and generates hype – so we are forever tempted to add more of that magic sauce into our applications. As software developers we should spend more time creating software that helps users align their mental models so that they can most effectively meet their goals. Ultimately, software is a tool; so let’s be very clear about making those tools easy to learn and as effective as possible once learned.