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.
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.
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:
- 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?”)
- 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.
- 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!
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:
- 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.
- 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.
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:
- Prioritization is way more fun and engaging. It also goes considerably faster than all of our individual release planning sessions did.
- The development team always has a clear idea of what our business needs are, and which of our tasks will provide the most value.
- 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.
- 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.
- 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!
There is a growing movement of people who are learning on their own, rather than relying on institutions of higher learning to provide the necessary structure and opportunity. The Internet has begun to provide access to information with ease and rapidity never before seen in human history. As a result, people who are interested in learning are able to do so without having to rely on the traditional gatekeepers of knowledge.
Evidence of this change is easy to find: The Khan Academy, Make Magazine, Instructables.com, and a whole wealth of podcasts and blogs on nearly any subject imaginable. The experts might still live in an ivory tower, but when that tower has broadband, the rest of us no longer have to make the pilgrimage to the tower to benefit from their expertise. And increasingly, experts seem to find those towers drafty and uncomfortable homes, and choose to be other places altogether.
Some schools have begun to embrace that change in various ways. Several members of my team at work have recently learned Objective C programming to create iPhone applications. Since Texas State University doesn’t offer any classes of the sort currently, many of us have worked our way through the iPhone development course at Stanford University — not by actually attending, but by taking advantage of the videos of the lectures and the supporting documentation that Stanford has published free of charge online.
While this sort of information broadcast is terrific, there is concern in academe, expressed at a recent Higher Education Leadership Conference, that this isn’t going far enough to address the changes that are coming, that in fact students are increasingly able to educate themselves, and will only rely on the University to accredit their learning, leaving Universities a husk of their former selves.
I think that change is indeed coming, and as someone who has a terrible time sitting patiently through classes just to learn the stuff I want to, I welcome it. However, I also suspect that the situation is not quite as dire for our institutions of higher learning as it’s painted. I know there are lots of people who benefit a great deal from having the clear structure and discipline that courses provide. And while the way of the self-taught is one that Universities haven’t embraced sufficiently up until now, giving them some long-overdue attention and validation doesn’t mean that the traditional student will vanish.
Different people have different learning styles, and educational institutions have to learn to grow to embrace them all, rather than flopping wholesale from one approach to another. Their future may just depend on it.
(Thanks to Jason for the link that set my thoughts going on this.)
All of you folks who are as interested in location-based gaming as I am have been checking in on Gowalla, Foursquare, SCVNGR, Facebook, Rally Up, or Yelp for a while now. But the lame thing about those services is that you actually have to go somewhere and do something to earn points! Enter Mojo, the web-location based game for folks who are shackled to their desks all through the day but still want the spurious sense of accomplishment that these games bring!
Teasing aside, it’s an interesting concept: allowing people to check-in on various websites and engage with the content there in various ways to earn credit. I’ve added it to the site here; feel free to play around with it if you’d like to see how it works. Just click that little “Earn Mojo” tab on the right to get started. (Though given how infrequently I get around to posting, if any of you earn the “365 Days in a Row” achievement, I’ll be forced to come over there and cut off your internet privileges. Don’t think I won’t.)
At the University where I work, there’s always a ton of Professional Development activity going on around campus, most of which is centered on training sessions for which people can register. That has always been an arduous, labor-intensive process, with real live humans handling every aspect of managing those registrations — reporting on class sizes, processing registrations, processing cancellations, maintaining a waiting list, communicating with attendees, etc.
To ease that chore, I’ve started work on a piece of software that manages all of those common tasks, driven by the requirements of our training organizations. So far, it allows a user to register for a class, cancel a reservation, subscribe to a webcal calendar that shows the training for which she has registered, download an ICS file to put the event on an existing calendar, receive email confirmations of registrations, to sign up for the waiting list for classes that are full, and to receive email notification when they get moved from the waiting list to the class roster. It’s also the most rigorously test-driven development I’ve done to date, so the code should be of good quality.
I’m managing it as an open-source project, so if you’re comfortable with Ruby on Rails and are interested in jumping in, or would like to download a copy to fool around with, you can visit the project on Google Code. I’d be delighted to have other contributers if it turns out to scratch anybody else’s itch as well. It is still very much geared toward folks who know a little bit about Rails and are willing to customize it to their needs. If that’s not you, you might want to steer clear for now.
At long last, the official Texas State University iPhone App is released!
The team brainstormed and prototyped the original version as a learning exercise at the beginning of the year, but once Marketing got wind of it, it quickly became a high-priority project. I’m really proud of my crew, who have all stepped up and contributed design ideas and code to the final product, which turned out really well.
We have some ideas for improving it going forward, and have plans to create an Android version as well, but are, for now, just delighted to finally have it out there in the world!
I wrote a piece about a year ago called Workplace Motivation and Game Mechanics which summed up some of my ideas for bringing some of the compelling character of video games to the office. Since then, some much smarter people have been doing some thinking and experimenting with similar ideas.
Jane McGonigal gave a terrific talk at TED called “Gaming Can Make a Better World”. It’s well worth the 20 minutes it takes to watch:
Additionally, I’ve started reading Total Engagement: Using Games and Virtual Worlds to Change the Way People Work and Businesses Compete. It covers the authors’ experiences in this area, starting with poolside conversations and ending up with forming a company around these ideas. It’s a good read so far.
Based on these, it looks like the invasion of games into the workplace has the potential to create some important productivity gains and is already underway. It should be fun to see what the next decade brings.
Over the past several years at the University, we’ve had to hire for a variety of programming and programming-related positions. One of the interviewing practices we’ve adopted is to give candidates a programming assignment which they can complete at home, at their own pace using any resources they can muster. Because these conditions approximate the conditions under which they would normally be working, we find this to be a really good indicator or what sort of work they’ll do if hired. (Besides, it’s one of the practices from The Joel Test! We currently score about 8.5/12.)
One of the jobs we’ve been hiring for is what I refer to as the “Quality Assurance Czar” — someone who will spearhead and organize our efforts to make sure the code we’re fielding is as awesome as we want it to be. The programming test for this includes both writing a small program to compare two hands in poker and, more importantly, writing a suite of tests to verify that the program works correctly. (This is not the exact programming challenge we use. It was actually one we considered, but it’s a thornier problem than one would guess at first glance, and there are a number of published algorithms out there already. We decided to make up our own problem so that applicants couldn’t just google for an answer.)
A few months back, one of my good friends — let’s call him Larry — interviewed for this position. He did a fine job in the interview, and while his code was very good, it didn’t include the comprehensive testing we were looking for. He wrote a small PHP application that generated a couple of random hands and then compared them, relying on the person running the program to verify that the winning hand the program chose was correct. His solution was 100% accurate, but didn’t include any automated tests, as he had a hard time imagining what sort of testing would have been useful in that case. Here’s a note he sent after the position had been filled:
I was real proud of my [Poker] app, the one that was supposed to include a testing approach. Now I’ve tried Selenium, and I still don’t see how to test my app, because it has no user inputs.
What did you guys ever have in mind?
Okay, I can see these tests:
- entering the URL brings up the page.
- A refresh causes a change to the page (a new checkers arrangement).
But that don’t seem adequate.
He is, of course, completely correct. While this would test a few trivial aspects of the application’s functioning, it would leave the important and juicy bit of code, analyzing the poker hands, completely untested. (This is called “incomplete code coverage” in the argot.)
There are several things one can do to make this application more testable. First off, one needs to create a mechanism to feed the program a specific input. Once you can do that, you can give it a couple of predetermined hands and verify that it chooses the correct one. Doing this with a variety of different hands will demonstrate that the program is working correctly in those cases.
There are, however, about 2,400,000,000,000,000,000 combinations of two 5 card hands. For obvious reasons, we can’t test all of those. How do we choose which ones to check?
Let’s start with easy ones. Verify that a flush beats a pair. Verify that a full house beats a flush. Verify that four of a kind beats three of a kind. Verify that a pair of 8s with hearts and spades beats a pair of 8s with clubs and diamonds.
Once you have the basics covered, we want to look for “edge cases”. These are where our data bumps up against boundaries of some kind. They’re very important because “off by one” errors are very common in programming, and these tests help to expose those errors. In poker, for example, we would want to check that an “A2345” hand would count as a straight, and that a “10JQKA” would also count as a straight, but that “QKA23” would not.
By this point, we’ve accumulated perhaps a few dozen tests — a miniscule percentage of the possible total, but strategically enough chosen that we have confidence that things are working as they should be. If we later discover that we’ve missed something and that our program is inaccurate in some cases, we simply add another test that demonstrates the failure, and then work on our algorithm until all the tests are once again succeeding.
Next, it’s important to try invalid data and make sure that our program handles the error condition as we would expect. Asking the program to evaluate a hand with 5 aces of spades is meaningless, and should generate an appropriate message for the user. (Something like “You’re a dirty cheating dog” might be appropriate.) Having the 17 of acorns as one of the cards in your hand is similarly out of bounds, and should also trigger an appropriate error.
In Larry’s program, all of the logic was stored in a single PHP file. Though it’s a bit more work to set up, I would recommend using a Model-View-Controller design pattern, and splitting the “evaluate the poker hand” portion of the program from the “show the poker hand on screen” portion and the “handle user input” section. By doing so, we can test these portions of the code independently. If we know that the code that evaluates the hand does so correctly, but it’s showing the wrong answer on the screen, we have immediately narrowed the code that might contain the bug to just the bit that’s responsible for presentation.
Finally, once we’re using MVC, it becomes practical to use one of the many excellent unit testing frameworks that encapsulate a lot of hard-won experience doing effective testing. Since Larry was working in PHP, PHPUnit and SimpleTest appear to be decent options. Using an established testing framework has a number of advantages: the code for common testing tasks (like logging into a site) will already be written, it becomes easier to integrate our tests with other systems, test output can be reported in succinct, attractive forms, and other programmers will have an easier time understanding how our tests work.
So, in summary, we’ve updated our program to accept input, fed it a number of test cases and verified that it’s returning the results we expect, adopted MVC and a standard test framework. We now have both a high degree of confidence that our current code is working as expected and a “safety net”: if we decide to refactor the program or change the algorithm we’re using to compare hands, we’ll know immediately if anything we’ve done has broken it.
For a more comprehensive introduction to testing and using it to drive development, see this article. And if you’ve followed this, want to learn more, and are interested in a job, our QA Czar position is open once again!
Last October, a couple of my coworkers and I presented at [High Ed Web 2008]. The conference organizers have, at long last, posted the transcript and audio recording of our session. The quality of the transcript is fairly rough, and they didn’t include the visual aids (which, by the way, I put a good deal of time into converting to a format they’d asked for), but the audio quality is good. If you have an interest in our experiences with content management systems at Texas State University, give it a listen!