Category Archives: Computers

Pebble First Impressions

Posted on by

I was a fairly early backer of the much-publicized Pebble smart watch. After being wristwatch-free for years, I’ve been wearing mine for nearly a week now, and have some early first impressions I thought I’d share for the curious.

First off: it’s a good-looking timepiece. While the 144×168 screen resolution sounds almost absurdly low for those of us who have been spoiled by full-color retina displays, it look just fine in context. The high-contrast display technology is great, and is visible in a wide range of conditions. Being able to turn on the backlight with a quick wrist-flick is terrific, though it does make playing hide-and-seek in the dark more challenging (as my kids will attest).

The on-device software is solid and well thought-out, with a clear, usable interface a bit reminiscent of the original iPod. Scroll views show a shadow at the top or bottom if there’s more content to display. Controlling music works like a charm with the built-in music app or any others that use Apple’s media control APIs. (Combined with Pandora and Apple TV, I can control music streaming from the Internet through my home sound system from my wrist. It’s the future!)

The included watch faces are fairly varied and interesting, with the binary display being a favorite of mine, though it takes me 10 seconds to figure out the time when someone asks me. And thanks to the support for notifications, I’ve known what those incessant chirrups coming from my phone are about without having to fish it out of my pocket.

Funnily enough, my biggest beefs with the out-of-the-box experience have to do with iOS. Pebble is taking advantage of some newer features in iOS 6 that haven’t been widely used yet, and there are still some rough edges on Apple’s side of things. Notifications have to be reset whenever the Pebble and phone lose contact with each other (which includes restarting either device, using Airplane mode, rebooting your phone for a system update, etc). Additionally, when the watch talks to the phone and the Pebble app isn’t already running in the background, iOS throws up an obtrusive alert telling you that the watch is trying to talk to the phone. It then launches the Pebble app into the foreground if you give it the permission to communicate it’s asking for.

There are, however, a few knocks I can level at the Pebble itself. If one gets multiple notifications in rapid succession — for example, when the mail app finds a few new messages in your inbox — the first notification immediately gives way to the latter, with no way to rewind and see the initial information.

The battery life doesn’t seem near as long as the advertised week. I admittedly haven’t run it into the ground yet, and I’m not 100% sure I gave it a full charge, since there’s no indication of charge status when it’s plugged in*, but so far it seems to last closer to 4 days than the week the company cites. (Oops — it just expired. Looks like the 4 day figure’s about right, and the low battery warning seems to appear 12-18 hours before it gives up the ghost.)

The most egregious problem, however, is the SDK. Or more precisely, the gaping hole where it should be. As detailed on http://www.ispebblesdkshipping.com/ (a spoof of Pebble’s own http://www.ispebbleshipping.com/), the kit that would allow developers to create new apps and watch faces for the Pebble was promised first for August 2012, then by January 23, then when the watch shipped. As of today, it still hasn’t turned up, and the company has been tight-lipped about what is causing the delay.

Given that the hardware specs have actually been improved since the Kickstarter finished, my hope is that the programmers are simply hoping to deliver something higher-quality and more capable than they’d initially planned on. The lack of communication, however, is a bit worrisome since many folks who have bought one of the devices did so out of a desire to be able to develop for it.

But overall, I’m happy with this first version of the Pebble. The existing functionality seems solid, and the possibilities for future improvements will be exciting once the SDK is finally out. If the company has to choose between putting something out soon that’s half-baked, or taking longer to create something they’re really proud of, it’s clear they choose the latter — a decision I applaud.

But now I have to go charge my watch.

* UPDATE: There actually is an indicator that lets you know when the watch is fully charged, but until the Pebble folks graciously pointed out the help page, I hadn’t been able to sort out the iconography they are using.

Why is Programming Fun?

Posted on by

One of the best explanations I’ve ever seen of the appeal of what I currently get to do as a profession.

Why is programming fun? What delights may its practitioner expect as his reward?

First is the sheer joy of making things. As the child delights in his mud pie, so the adult enjoys building things, especially things of his own design. I think this delight must be an image of God’s delight in making things, a delight shown in the distinctness and newness of each leaf and each snowflake.

Second is the pleasure of making things that are useful to other people. Deep within, we want others to use our work and to find it helpful. In this respect the programming system is not essentially different from the child’s first clay pencil holder “for Daddy’s office.”

Third is the fascination of fashioning complex puzzle-like objects of interlocking moving parts and watching them work in subtle cycles, playing out the consequences of principles built in from the beginning. The programmed computer has all the fascination of the pinball machine or the jukebox mechanism, carried to the ultimate.

Fourth is the joy of always learning, which springs from the nonrepeating nature of the task. In one way or another the problem is ever new, and its solver learns something: sometimes practical, sometimes theoretical, and sometimes both.

Finally, there is the delight of working in such a tractable medium. The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures. (As we shall see later, this very tractability has its own problems.)

Yet the program construct, unlike the poet’s words, is real in the sense that it moves and works, producing visible outputs separate from the construct itself. It prints results, draws pictures, produces sounds, moves arms. The magic of myth and legend has come true in our time. One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be.

Programming then is fun because it gratifies creative longings built deep within us and delights sensibilities we have in common with all men.

From The Mythical Man-Month, by Frederick P. Brooks, via Federico Grilli

Back in My Day…

Posted on by

…we didn’t have fancy 3D graphics! We had half-acre pixels and 8 colors and we liked it!

Today while visiting garage sales with my lovely bride, I stumbled across an October 1982 National Geographic with these ads for game consoles of the day. I was 12 when these ads were run, and remember fondly many hours whiled away with friends playing both Atari and Intellivision. (I never did much with the Odyssey², probably because I saw these ads and the “wizard” gave me nightmares.)

Intellivision Ad

In 1982, these screenshots actually looked different from each other.

Odyssey Ad

The Wizard has a Power Supply stuck to his fingers. Also, his legal department apparently lacked the acumen to get a proper "Wizard of Wor" license.

Odyssey Speech Synthesizer Ad

If the first word you typed upon getting the speech synthesizer module for the Odyssey² was "Geewizbang", it's a pretty good bet you had no friends.

Going Mobile

Posted on by

On January 2, I”ll be going to work for Mutual Mobile, an Austin-based company that specializes in application development for iOS, Android and Blackberry devices.

“But Sean!” I hear you, Rhetorically Convenient Reader, cry. “You just started working for Magnolia back in March! Why are you moving on again so soon?” That’s a good question. It doesn’t have anything to do with Magnolia: it’s a terrific company, filled with great people that I am glad to call coworkers and friends. That fact made this decision especially hard, as I knew I’d be seeing less of these people I quite like (and would, honestly, be making their lives tougher in the short term with my departure).

But as much as I like Magnolia, the nature of their business means that my work there revolved around two things: Java and Sales. Java is an industry standard for creating software of various stripes, but it’s a very buttoned-down, staid environment to work in. It lacks the creative energy and — is it silly to say this? — joy that I see in the communities that exist around some of the more dynamic, less-widely used languages like Ruby and Python and Lisp (for you AI wonks out there). I can get work done in it just fine, but the number of times a spontaneous “Awesome!” escapes my lips while doing so is vanishingly small.

The other focus of my last 9 months has been selling Magnolia to various companies. I think the software is a phenomenal piece of work, and really well-suited to a whole variety of Web Content Management scenarios. But while I can do an effective job helping to demonstrate and sell it, there’s no frisson associated with doing so for me.

I like technology for what it can do for people. I like creating it because doing so is much like fashioning a beautiful, intricate bit of clockwork, or a complex bit of musical counterpoint. There is immense satisfaction in creating something that works elegantly and beautifully. Unfortunately, telling people about how terrific other people’s work is provides very little of the satisfaction that actually doing that creative work oneself. If I’m going to be in the technology world, I want to make cool stuff for normal people, not to sell cool technology to corporations.

So, Mutual Mobile. I’ll be starting there as an iOS Manager, which means that not only will I be getting to work directly on creating some great stuff for their impressive list of clients, but I’ll also be getting to help figure out the best way to help the other developers there do their best work as well. I’ll be hanging around a bunch of really smart folks, and will doubtless be learning tons about iPhone development and other mobile disciplines. The company seems like a marvelous place to hang one’s professional hat — a vibrant company culture, entirely self-funded with no investor money involved, just named by Forbes as one of America’s most promising companies, and has its company meetings at the Alamo Drafthouse, one of my favorite places in Austin. And the downside of facing a commute again is largely ameliorated by the fact that Texas State University runs a shuttle bus from San Marcos with wireless Internet to a park 4 blocks away from the office. Sweet!

I’m excited about this next adventure, and will be posting more about it once I’ve got my feet under me. Wish me luck!

Humanities and Technology

Posted on by

Yesterday the kids were off from school for teacher conferences. We started off with 10 young people under the roof, thanks to sleepovers, with the remainder of the day continuing in the same busy, wild vein.

And then, on the way to pick up a collection of teenagers from the river, I heard on NPR that Steve Jobs had died.

I had never met the man, and was surprised to realize how sad the news of his death made me. As I’ve mulled over various tributes and retrospectives, I’ve come to a better understanding of why that is.

The products and technology he brought about have, of course, been a large part of my personal and professional life. His commitment to excellence has been inspirational, and his drive to achieve great things stirring. His charisma and capability as a leader were instructive.

But the most interesting, distinctive thing about his career and success is this: its humanism. While the rest of the industry has often been content to make computers do what computers do better, Mr. Jobs had an unwavering focus on using technology to help people do people things.

What do people do? We communicate. The iPhone, Facetime, and iChat spring from this desire. We make and enjoy art. iMovie, Garage Band, iPhoto, and the iPod all have their roots there. We enjoy relationships with other people. Thus, integration with all sorts of social media, facial recognition technologies, etc. We tell stories. Pixar does some of the most brilliant storytelling of our generation. (“Up” made me misty-eyed in record time, and “The Incredibles” remains one of my favorite films ever.)

For many technologists, the instinctive thing to do is to span the gap between people and technology by having the explorers build a precarious rope bridge which will allow the tenacious to, with a good deal of effort, make it to the other side. Steve’s unique genius was that, having made it across, he then turned his fellow explorers right back around and had them build a sturdy, capacious, beautiful bridge for the rest of the world to follow the explorers.

Indeed, he made technology “for the rest of us” — not so that we could have better gadgets, but so that we could ultimately have better, richer, more fully human lives. Thanks, Steve.

Free Stanford AI Course

Posted on by

This October, anyone can take an Introduction to Artificial Intelligence class, taught by professors at Stanford, for free.

This is great. But it gets better. In order to expand the scope of the class from the 200 people they’ve been teaching in person, the instructors will be using AI software to grade homework, aggregate discussion questions, and generally mediate interactions with students. Why bother? Because, to date, over 100,000 people have signed up for this course, and the enrollment is showing no signs of slowing.

The use of the software to scale allows students to get feedback on their individual homework assignments and quizzes, to interact with the instructors, and to get a ranking in the course compared to both other online attendees and the students enrolled at Stanford — feedback that would be utterly impossible to provide to that number of people if the instructors didn’t have the help of AI. It will be fascinating to see how the concepts taught in the class are used to administer it.

I’ve been intrigued by AI ever since reading Gödel, Escher, Bach way back when I was a teenager (and before I was really equipped to follow all of it). More recently, I’ve been increasingly interested in robotics and the applications thereof, which rely pretty heavily on some of the AI concepts that are in the syllabus for this class. And, of course, I have an enduring interest in games, which are probably where AI is used most often in modern computing.

So am I signing up? You betcha. And I hope some of my nerd friends will too, so that we can compare notes along the way.

This is one of the reasons I love living in the future: we have access to information and learning that is unparalleled in human history, opportunities to sit at the feet of experts that we could only have dreamed of even a decade or two ago. And wonderfully, access to an amazing education is increasingly being divorced from access to money, creating remarkable opportunities for people who are ready to work at their own learning, regardless of their backgrounds. I fully expect to be bested in the course rankings by smart 14 year olds in India and China, and will be excited to see it happen.

I’ll post some updates and reflections along the way, and possibly homework assignments too if they turn out to be interesting. This should be a fun ride.

(Thanks to Singularity Hub for the tip-off.)

New Programming Blog

Posted on by

For those of you who have an interest in programming in general, Magnolia in particular, or just can’t get enough of my scintillating writing, I’ve started a new blog over here: Propeller Hat. It’s mostly Magnolia stuff thus far, and will probably be infernally geeky for the foreseeable future, so only visit if you have a fairly high tolerance for that sort of thing.

Virtual Photography

Posted on by

Back in 2001, CBS introduced EyeVision for their Superbowl telecast. EyeVision allowed the broadcasters to combine images from several dozen cameras, positioned and 7° intervals around the stadium, into a seamless playback that could be rotated on the fly, creating an effect much like the famous “Bullet Time” sequence in The Matrix. The technology, while not perfect, was really neat, and offered unparalleled insight into the on-field action. Unfortunately, it hasn’t made a reappearance at a Superbowl since then, and the technology doesn’t appear to have been pushed forward much.

Fast forward to 2011. The Kinect has been released for the XBox 360 and has been enthusiastically embraced by hackers. Microsoft, while initially reluctant to let people fool around with the sensor, quickly realized that they were fighting a losing battle, reversed their position, and now even provides some official support for people doing new and interesting things with it.

The Kinect works much like a WebCam: you point it at something, and it gives you a video feed of what you’re pointing at. The interesting thing, however, is that in addition to the image, it also tells you how far away each element in the image is. Using a couple of Kinects in tandem allows one to actually reconstruct a texture-mapped scene in three dimensions. Once you’ve done this, it’s a simple matter to move around and through the space, much like you would in a video game. Here’s the first proof-of-concept I saw:

And here’s another demonstration that uses a single Kinect panning around a scene to capture the data:

As you can see, once the data is assembled, one can move a virtual camera through the scene, viewing it from angles where there was no camera to begin with. Though these first efforts are still a bit rough, think what one could do with this sort of technology if it were refined and made more sensitive: the Superbowl’s EyeVision technology could be expanded: instead of 33 possible vantage points, you could see a playback from an infinite number of angles, even swooping in among the players. Movies could be filmed with full 3D data sets, allowing one to move through a scene and see it from whatever angles one wished. Professional photographers could not only adjust exposure, contrast, saturation and that sort of thing, but also the apparent angle from which a photo was taken.

I expect this sort of thing to blossom over the next few years, and am anxious to see what happens with it once it gets from the hands of hobbyist technologists to those of artists and producers. It should be a fun ride.

Time for a New Adventure: Magnolia

Posted on by

Last Thursday, I gave my one month notice at the University.

The reason for that was not any particular discontent. While the University has its share of bureaucracy and silly decisions, the management above us has generally shielded us from much of it. And being able to walk to my office, have the freedom to explore lots of crazy stuff as the mood strikes, hone my management skills, have a stable job, and work with some terrific people on a beautiful campus has been great. I’m proud of the work we’ve done, and proud of my team, which has accomplished an amazing amount with minimal resources.

But now I’m going to work for Magnolia, the Swiss company that makes the CMS software that we’ve been using at the University with great success for a number of years. I’m excited about the change for a number of reasons:

  • They are a great team. I’ve worked with Magnolia as a customer for about four years now, and have been really impressed with both the technical excellence of their work and the professional excellence with which they run the business. I also got to meet many of them at the 2009 Magnolia Conference, and was delighted to find that every single Magnolian I met was genuinely kind and pleasant as well. What a great combination!
  • I’ll get to focus in on programming again. While I’ve enjoyed stretching myself into the role of a manager over the past several years, and think I’ve done some interesting and positive things in that position, I do find myself enjoying work the most when I’m able to focus on technical disciplines. While I don’t see a ton of opportunity to exercise the Objective C and Rails skills I’ve built up at the University, I expect there to be plenty of space to go as deep as I’d like with Java.
  • I’ll have the opportunity to do some traveling, both to Basel, Switzerland, where the company is based, and around the United States to get together with other members of the U.S. team, visit customers, and present at conferences. I hope to be able to bring Kathy and the kids along at times too, so that we all are able to benefit from the travel and see a bit more of the world.
  • I’ll be working from home. I’ve done a fair bit of this is previous jobs, and have always found it to be a really nice arrangement. Kathy is great at running interference so that I can really focus when I’m “at work.” But when I’m ready for a break, the family is right there, so it’s easy to have lunch with them, take them down to the park for a bit, or mount a quick trip to the river for a swim.

The new job will include technical pre-sales (talking nerdspeak with prospective customers and building prototypes for them), working on internal projects, raising awareness of Magnolia in the US by participating in community discussion and presenting at conferences, and providing support to existing customers while the team in Switzerland sleeps.

My last day at the University will be Thursday, March 3. I’ll take that Friday off to go blow some things up with Jason Young (we’re planning on building a jam jar jet engine), and will then dive in at Magnolia on Monday, March 7.

The Penny Game: A Way to Prioritize Tasks Among Many Projects

Posted on by

I’m a fan of agile practices in programming, and encourage my team to work along agile principles as much as possible. One thing that has always been tricky about that for us, however, is that we don’t really match the usual profile of a software team.

Most agile teams (at least in the literature) are focused on a single project, and have multiple people working together to get that project done. We, on the other hand, do all the development work for Texas State University’s Learning Management System (about 32,000 users), Content Management System (287 sites at current count), an Event Calendar system, the University iPhone app, a reservation system for training classes, a custom web content caching system, various custom-built content management systems for accreditation and regulatory compliance, and a bevy of internal tools — all with 6 people.

Needless to say, I’m very proud of my team.

Prioritizing the time of six people when we have ongoing responsibility for more than twice that many projects is, however, a daunting challenge. Our approach for a number of years had been to set release milestones for each project, to do release planning meetings to determine what should go into a given release based on our Planning Poker estimates, and then to try our best to get the work done in time.

This approach had a few problems:

  1. Release planning meetings were long and boring. We would walk through the list of unresolved tasks for a given project one by one to see if anyone wanted to prioritize that task. 90% of our time was spent saying “Ticket #666: add a green widget to the defrobulator. Anyone interested? Anyone? Class? Bueller?” (Only to have Bueller pipe up three tickets later: “Can we go back to ticket #666 for a minute?”)
  2. It was easy for people who had an interest in one project to commit 100% of the development team’s time to that project, while folks who were keen on another project would commit all of our time to that project as well. Our planning process didn’t reflect the fact that all the projects were competing for the same resources.
  3. If we finished all of the tickets for a release early and had extra time (a pretty rare problem, admittedly), we didn’t know what to work on next.

So a few months back, I decided to try an experiment. I got the stakeholders for all of our projects in a room together, gave them each 10 pennies, and explained to them the rules of the game:

“Today you are going to help the development team set our priorities. You each have 10 pennies, which represent tasks you can vote for. In order to vote for a particular task, write it on an index card, put that card in the middle of the table, and plunk down as many of your pennies as you’d like on that card. You can use all of your pennies on one task, or spread them among as many tasks as you like. Also, I encourage respectful argument. Try your hardest to persuade the people around you that they should put their pennies on the tasks you like as well. When we’re done, the number of pennies on a task will help determine its priority for our team.”

Good natured chaos ensued for the next 30 minutes as we wrote cards, passed them around, combined them, discussed the relative merits of the tasks ahead, bumped into each other as we moved around the table, tried to figure out what the heck some of the cards meant, and generally made a mess of the conference room we were working in. When we were done, we had a big, unruly pile of index cards with big, unruly piles of pennies on each:

After the meeting’s conclusion, the dev team took another 15 minutes to count the pennies on each card and put that count into a special “Bounty” field in our ticketing system, creating new tickets as needed. (We use “bounty” and “pennies” interchangeably.) When I was done, I told the system to sort our tickets by bounty, and suddenly had a prioritized list, across all of our projects, of what tasks had the most business value. Beautiful!

Task List Sorted by Bounty

Task List Sorted by Bounty

Of course, the number of pennies on a given ticket doesn’t directly determine the order in which we work on things. We also factor in the estimates for a given task we’ve come up with individually or during our Planning Poker sessions. One can divide the pennies by the estimated hours to get a “bang for the buck” rating for each of the tickets — a much more useful way to prioritize one’s work.

I don’t like to assign tasks to people on my team directly more than necessary. I find people to generally enjoy work much more when they are able to make their own decisions about what to spend their time on. On the other hand, I do want us as a team to provide the most real value we possibly can to our various customers. Since the penny game provided us a “here are tasks with business value” list, I decided to provide a couple of incentives for folks who were completing those tasks:

  1. I took a bizarre southwestern style pot that I had sitting around, labeled it the “Pot of Honor”, and told the team that it would be filled with candy and awarded to the team member each week who managed to complete tasks worth the most pennies during that span. Battling for the dubious honor of having this homely artifact rest on one’s desk for the week provides some silly, low-level competition and recognition for individuals.
  2. I set the team a collective, cumulative goal and told them I’d take them to lunch when they reached it. When we tally pennies for the awarding of the Pot of Honor, we also add up the number of pennies the whole team has completed and add them to a running total. Progress is noted on our work-area whiteboard, so we can all see how close we are to getting to have free food.
The Pot of Honor

The Pot of Honor

I’ve also made space on the whiteboard in our team area where we have our daily stand up meetings to put up the “Top 10” list of tasks that have accumulated the most pennies to help maintain focus on those high-value items.

The next time we played the penny game, a month later, it went much more quickly: we already had cards on the table from the last meeting, everyone had a better idea of what we were doing, and some folks had looked through the tickets in advance to see which tasks they wanted to support. I was surprised to see that, as we got more practiced, we were able to finish the entire exercise in about 20 minutes. We simply added the new pennies to the existing bounties in the ticketing system, making them increasingly juicy as they got older and people still had interest in them.

We’ve been playing the game for a number of months now, and I count our experiment a solid success. Advantages it has provided for us:

  1. Prioritization is way more fun and engaging. It also goes considerably faster than all of our individual release planning sessions did.
  2. The development team always has a clear idea of what our business needs are, and which of our tasks will provide the most value.
  3. Stakeholders cannot say “everything is top priority”, but are forced to choose where to allocate their pennies. The finite scarcity of pennies reflects the limits on developer time.
  4. Individual developers can exercise a good deal of autonomy and choose their own tasks while we still, as a team, deliver on the things we need to.
  5. There are a number of tasks that, while people say they are important, apparently do not merit the expenditure of a penny. As these persist for a sufficient period of time without accumulating any pennies, we can close them as not really being a high priority. (We can always reopen them later if someone decides to spend a penny to raise them from the dead.)

We’ve introduced a few refinements as we’ve gone along: Because some of our systems have tens of thousands of users, it’s ill-advised to get all of the stakeholders in a room at once. To account for this, we give the support staff extra pennies to distribute as proxies for the absent users. We’ve started writing project names and ticket numbers on the index cards to make it easier to correlate them to our ticket system. We’ve begun bringing as many laptops and iPads as possible to the meetings so that people can see the details on the various tickets in question. We now add a penny to each task whenever a user request comes into our support team.

I should note that during the time I was designing this process, I was also reading through Total Engagement, and consciously built in many of their 10 Ingredients for Games: Feedback across a range of time scales (completion of individual tickets, weekly discussion of bounties cleared, longer-term goal of team lunch), Reputation (the awarding of the Pot of Honor), Marketplaces and Economies (the game itself is a market to “buy” the development team’s time), Competition Under Rules that are Explicit and Enforced (there’s no ambiguity about how many pennies are on a ticket or how they’re assigned), Teams (working toward the common lunch goal), and Time Pressure (weekly tallies of points, implicit time pressure of not wanting to be the last person with pennies left to spend while everyone else sits around). I think these elements have been critical in making this a more engaging way for us to do things.

So, if you’re facing a similar challenge with more projects than you have people, feel free to swipe any of these ideas that look helpful. I hope they’re of some use to you. If you do give the penny game a try, please post here and let me know how it goes. Good luck!