Now that the concept of gamification has become (even too much) mainstream, it is not surprising that this is not the first time an idea like this is proposed. Jason Rudolph has published an excellent blog post about programming achievements. Websites like coderwall already inspect source code repositories on GitHub and others in order to build achievement-based profiles for coders. There even is an earlier project, called Strokes, that added achievements and challenges to Visual Studio.

Introducing mainstream achievement support right within the IDEs, however, can have a stronger effect on the way we write software, as those tools can inspect code right while we are writing it. The strong link between action and reward lead to a stronger feeling of accomplishment when we earn those achievements, and programmers are likely to be receptive towards game mechanics (most of us have a background as gamers). But there is more than that.

How it works

Most of the newly introduced achievements promote best practices, such as the Good Housekeeping group depicted below. Some of them are triggered by specific events, such as coding on a Friday night, while others take unlikely activities and award achievements just for the fun of it. The full list is available on this page.

There is also a more interesting set of achievements, appropriately called Don’t Try This At Home, which is way more controversial than all the others (and it resulted in a quite mixed set of reactions in the comments and on other blogs). Here are three examples:

The achievements in this group are awarded as a consequence of using some commonly recognized bad practice, typically something that results in unreadable or unmaintainable code. They are given a sort of negative connotation, since most of them are not not worth any points (and some readers even proposed to actually subtract points) but they are still called achievements, which will certainly lead some coders – typically the ones with strong collector habits – to indulge in bad practices just to get all the possible badges.

And yet, even this initial implementation is a significant proof of how such a system can be used to influence the way we build software, even if at a low level. Since programming is not just a game, let’s see if we can design achievements to actually help us writing better software.

Taking it to the next level

Regularly running static code analysis tools can give so many benefits that, as John Carmack points out, it is just irresponsible not to do it. However, especially with large and old code bases, even when such tools are used their output is neglected and they get discarded after a while. Often it takes the willpower of some good souls who choose to sacrifice their own time to fix all the defects that have been accumulating for months.

Gamification and achievements can be just the right nudge we needed to win the latent resistance towards static code analysis, as they can regularly inspect the code we write and give prompt, frequent and consistent feedback about how we are doing. But instead of presenting us with a flat list of warnings and notice, they can give us feedback in a more pleasant and personal way, as part of a wider system designed to add some fun to our chores.

The ideal system would be designed according to a few key principles, such as the following ones:

• focus on positive change – by rewarding updates that increase the quality of the code base, more than one-off activities
• use positive framing – instead of punishing bad behaviour (e.g. by subtracting points), encourage good habits that last
• make cheating unappealing – if too much importance is given to the achievements themselves, users may try to “game” the gamification system, engaging in fake activities just to collect all the possible badges, or to get a higher score (that is why I am not fond progress bars, percentages and the whole concept of “missing achievements”)

Conclusion

As it often happens when games cross work and real life, ideas like this are bound to be controversial. On one side, we may see them as just adding some meaningless dimension to our day to day activities. On the other hand, we can benefit from the additional enthusiasm and motivation achievements can instill in us. Some people, like Reeves and Reed in Total Engagement (p. 169), even suggest that building skill- and level-based profiles of employees and coworkers can result in better performing teams on the workplace.

Personally, as someone who has spent a significant fraction of his own lifetime playing games, game mechanics can have a big influence on my behaviour and engagement (even if I try to be aware of that happening). I believe that a well designed system can help a great deal in making positive behaviours and habits come more naturally.

Maybe achievements will not be that relevant for expert coders who are already passionate at what they do but, if used effectively, they can lead newbies to invest more in learning best practices and mastering their tools. Indeed, inducing good behaviour is better than imposing it.

So, when can we expect to see something like this on other platforms?

While issue trackers originate as tools to manage projects more effectively, during the last years of work I have been through some situations where their misuse backfired.
Tools originally conceived to improve workflows and project lifecycle became a significant burden for the team using them, occasionally making difficult situations even worse.

This post is a collection of bad patterns I have seen happening. It is not a survey of all the possible situations that can occur. It is not meant to be an argument against issue trackers (if it tells anything, it will probably be about the teams I was part of), but rather an overview of things that went wrong because of the way a particular team used those systems.

In retrospective, most of the problems were due to a lack of discipline and experience of the project teams, and they are less frequent – if present – in a team of seasoned professionals. But, while training and education can certainly help, I would love to consider a different aspect: the issue tracking systems were not helping as they could have.

Here is a summary of the most common and annoying problems I encountered

• The issue tracking system is misused
• Lots of issues are duplicates
• The system imposes over-engineered processes
• Bug reports do not include enough information
• The way priorities are managed is broken

The issue tracker is misused

While it should be obvious that an issue tracker is a tool to track issues, they are sometimes used for other kind of communications.

The screenshot above is just the most recent example of misuse I have seen. The issues on the tracker should be items that can be acted upon, it is just not practical to use them to discuss features or to gather requirements.

A smart issue tracker should recognize questions and conversations and warn users when they are about to post them, just like Stack Overflow does in the screenshot below.

Plenty of duplicates

Duplicate bugs are a frequent pain point for many project teams, to the extent that a frequent suggestion is penalizing testers who open too many duplicates (and this may not be a great idea, after all). While they certainly can be minimized by a disciplined team, they still are likely to occur when a large team is testing a complex software product.

Avoiding duplicates is as easy as performing a search among the existing issues, but it is time consuming, so this step is often neglected. A smart issue tracker would automatically perform this step on behalf of the user and display a warning if it finds issues that look similar enough to the one being reported. This is exactly what happens when posting a new question on Stack Overflow (and somewhat similar to what Quora does): questions that look suspiciously similar to the one entered are displayed right next to the input area.

A diligent user would realize that there’s no need to add another issue if prompted with a match, but the system would never prevent the operation from being completed: a suggestion is better than an imposition, and users should be able to make the final decision.

Over-engineered processes

Many issue tracking systems offer a very basic set of default states and properties, and allow their users to do many customizations to them from the settings page.

In the project I am part of, we use Redmine with a set of plugins oriented towards Agile methodologies. The default set of states and processes in Redmine has been customized to suit the project needs. Needless to say, strange things happened. All issues have an optional property “Assignee”, as expected by a system of this class. For some strange reason, however, we also have a state for issues called “Assigned”.

This redundant “Assigned” state information does not add any value to the process, it just adds one mandatory and uninformative step to the lifecycle of all issues. All the information it conveys can be derived from the presence or absence of value in the “Assignee” field. To make things worse, we can have issues in inconsistent state, with an empty “Assignee” field and state “Assigned”.

The process we ended up having for all of our tasks and issues can be simplified without loss of generality to the set of states and transitions offered by Pivotal Tracker, like the ones shown here. The only difference is that state transition in Pivotal are accomplished by clicking a button, while they are much more cumbersome in Redmine, since we need to update multiple fields at the same time.

A good issue tracker should come with a set of sensible defaults, but powerful enough to handle most situations and state transitions should be as easy as clicking a button.

Configuration should be an option, not a requirement.

Missing information

Reports without instructions about how to reproduce the bugs, screenshots of error pages, one-line reports without log extracts are frequent time-wasters.

During the last few months, I have lost count of the times I have seen issues being reopened without any other information, just to discover that the test progressed but the code was breaking at some later point.

While this kind of problem is often due to inexperience, a good tracker would induce (rather than imposing) bug reporters to supply enough information. (e.g. by not allowing to reopen an issue without supplying any information)

Google Code allows project owners to specify a “new issue” template that looks like the following:

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?

A template is an effective way to communicate what the team needs to know in order to solve issues. It encourages users to include useful information, and makes empty reports the less natural choice (reporters have to explicitly blank out the form).

Broken priorities

The difference between the severity and the priority of a bug is often a source of confusion, even for people who have been working on issue trackers for a long time.

The severity of a bug depends on the impact it has on the underlying system, it is a functional measure, and can be estimated right when opening an issue.
The priority of a bug is a scheduling decision, depending on business requirements, time required to fix and several other factors.

Severity and priority are clearly two different concepts. Although they are correlated (high severity should generally mean high priority, but not always), they represent different concepts. For example, an issue priority can change after a rescheduling, while an issue severity can hardly change unless something changes.

There are different schools of thought about how to deal with this duality, ranging from supporting two different properties to two getting rid of one of them (e.g. FogBugz dropped “severity”).

In the last project I was working on the choice fell on the latter (we used Redmine, which supports priority by default and allows users to define custom levels). Now, while this is not a problem by itself, the highest possible issue priority configured was called “Blocker”.

At this point it should be evident about what the problem was: we were confusing scheduling with impact, automatically assuming that any issue that was blocking something else (yes, it was as vague as this) had higher priority than anything else.

To make things worse, we were using Redmine to track also our user stories and the features to be developed. What would a “blocker” priority mean, in that setting?

The chart below shows the result of this policy: in the last two months, 1 issue over every 4 was considered blocker.

The highest priority should be considered an exception, when it becomes the norm it ceases serving its purpose. “Blocker” was no longer informative, and bugs marked as such were only marginally more important than the others, which is something I do not want to see happening again.

A significant part of the responsibility is due to the confusion between priority and severity: there is no such thing as a “blocker priority”. If it is needed to track severity, there should be an option only for bug entries (not for tasks, chores and features).

The priority of a bug is a matter of planning and should not be set at the time of its discovery. A minimal triage process would have prevented most bugs being set as “blocker” just because they were blocking some automatic test routine.

A smart issue tracker would warn users when it detects that a significant part of the issues in the system have the highest priority, ideally right when they are about to open another issue using that level.

Conclusion

As it often happens, most of the problems do not depend just on the tracking systems themselves, but are caused by the way users interact with them. As said before, training and education can help a lot in minimizing the kind of patterns mentioned before, but better designed issue trackers can go a long way in reducing the possibilities for misuse.

Sites and applications on the Internet are becoming more and more powerful and refined in design. It is possible to guess what users are trying to do and induce them to use the systems we design in a proper way. It is possible to make small changes that point users in the right directions, and the previous sections offer some examples from the real world.

We can do better than punishing users when they do something wrong. We can design applications that realize when users are about to do something wrong, but instead of issuing an error message and aborting the action, they warn them, and point them in the right direction.

We should start designing issue trackers as if we were designing any other sophisticated application on the Internet.

How would you explain to a 12 years old what an API is?

At first, I was surprised: it certainly sounded like an uncommon question for a Software Engineering interview. And yet I tried to answer as best I could, trying to come up with a concise definition that could convey what I meant, but without assuming any specialist knowledge about computers and software.

As I progressed with the interview, it became evident what kind of ability my interviewer was trying to test.

Whatever is the job we do, there is a good chance that we will need to interact with other people multiple times a day to get things done. However, the ability to communicate effectively is often overlooked and it is rarely a skill that is taught at school.

While we have no difficulty in interacting with other people in the same profession, things can sometimes go wrong when we meet someone with a totally different background.
Have you ever tried explaining virtualization to a customer?
If at some point their attention faded, they openly told us they could not understand what we were saying or we saw terror in their eyes when we met them during the following days, it is generally not because they are stupid, but probably because we are doing it wrong.

(Even if you are not from the IT field, you have probably been in a similar position. This post may apply to your experience as well.)

So, how can we get better?

Here is one trick that can help a lot.
Spend time with children. If they are the curious, inquisitive type that always ask questions like “Why do airplanes fly?”, even better!
In addition to being fun, explaining complex concepts to children turned out to be one of the most valuable exercises in communication I ever had the chance to try.
Even if we are not dispensing unsolicited lectures, but we are rather asked a random question, chances are we will learn some interesting lessons about children.
Here are some examples:

• They do not possess the same knowledge as we do → It is not that they are stupid: we just have to choose the proper language for them and pick the right level of abstraction
• Their attention span is generally limited → We must be concise, stay on topic, and we should not answer their question starting from too far
• They are not as much interested in the subject as we may be → There is no point in delving into details that are irrelevant to them. We must know when to stop: never start a treatise on Nuclear Physics when asked why stars shine.
• They pay little attention to pure abstractions → We must leverage examples and analogies

It turns out that those principles are exactly the same ones you could use to explain an abstract technical concept to a non technical colleague. It will not probably work for lambda-calculus, but I assure that it works for virtualization and many others.

But what if I hate children?

There are other activities that help getting better at communicating ideas. Here is a list of the most obvious ones, along with some non-obvious considerations.

• Read – good books are able to engage us and keep up our attention. Fiction is fun, but try to read some non-fiction about some subject you are not an expert about. By doing that, you will be in the exact situation as your non technical colleagues when you try to explain something from your field. Look for patterns that work (e.g. metaphors and analogies) and try to make them yours.
• Listen to good podcasts (e.g. Radiolab about science, Planet Money about economics) – those are a great example about how you can take a complex subject and make it accessible to almost anyone.
• Practice writing – written communication is a lot different from speech. Writing on a blog is a good starting point, but keep in mind that email works only if you write concise messages that can be acted upon. Focus on brevity and meaning.
• Teach – Teaching offers a great incentive in delving deeper in the fundamentals of your profession, but it also forces you to pay a lot of attention about whether your message is getting across and keep the right pace when explaining things.

While I still have lots to learn, I feel that in more than one occasion I was able to solve problems because I cared about expressing concepts in an effective way. I am still looking for ways to improve in this, however, so if you have any advice, please share.

I didn’t want to go through the hassle of setting up Apache on my Mac, though, and I was looking for some quick alternative to installing a local web server. After some Googling, I found a wonderful one liner that did the job, provided that you have Python installed.

Open a Terminal window and go to the directory containing the files you want to serve and run:

python -m SimpleHTTPServer

or, if you are using Python 3,

python -m http.server

you will then be able to access your files on http://localhost:8000/. (You can specify a different port number by passing the number as last argument, just remember that you need root permissions to open sockets on ports lower than 1024.)

Sometimes radio announcers say it immediately after, but some other times (most, actually) they do not, leaving no alternatives other than firing up Shazam to discover what is the song you like. And, well, if you are driving, that generally is a poor choice.

Now, just think about how we could redesign that process to make it more effective, using present-day technology and infrastructure.

Here is one possibility I would love to see happen.

Most cars are designed with a display meant to show miscellaneous information (including the name of the radio station you are listening to).

Now, imagine radio stations could use that display to show information about the song they are playing, and users would be able to press one single (physical) button to buy that song using some online store (iTunes, Amazon or some other alternative).

While this situation would require the convergence of effort and interests of several actors (radio stations, car manufacturers, music labels and online stores), it could lead to new business models, where radio can generate explicit leads just as Internet ads do.

That would the perfect setting to encourage impulse purchases, allowing people to purchase songs they love right after they hear them.

If that is difficult to implement right now, maybe we just have to wait until we can have Android-powered car systems. If cars had a 3G connection and could leverage a proper ecosystem of apps and services, we can imagine a large number of new services, giving the term “mobility” a new and richer meaning.

I have received my Kindle as a gift at the beginning of this year, and it quickly became my favorite gift of all time.

That can be quite surprising, knowing me. I own many different devices, gadgets and computers, but I have always been fond of the smell and feeling of paper books. Knowing that, some people were ready to bet that I would use the Kindle for just a few days and neglect it shortly after for something else (e.g. my iPad).

I must admit that I am sure this is exactly what would have happened with any other e-reader device. My experience with the Kindle, however, was (surprisingly) awesome, and it due to reasons I didn’t expect.

While the reader by itself is a great device under any aspect that matters (i.e. it is light, fast and the battery lasts weeks), the number of services Amazon built on top of that make the experience with the Kindle even better.

As you probably know by now, you can buy books directly from the device, you can send your files and documents over email, it automatically downloads new content over WiFi or 3G connections.

What I found incredibly useful, though, is the ability to read any book I downloaded from Amazon on any of the devices I use (whether it is a PC, a Mac, a phone or an iPad) by using the dedicated apps Amazon built for each of those.

All apps and devices are able to sync wirelessly, without the need for any cable connection to a computer. Even more important, any progress you make while reading the book is synchronized to all the devices you use to read it.

So, imagine the scenario, even if you read 3-5 pages of a book on your cell phone while waiting in line at the post office, the next time you pick up your Kindle you will find yourself at the right page. Isn’t that great?

I still miss this kind of feature every time I need to semi-manually manage 1-hour podcasts between my iPod nano, iPad, work and home computers. I’m sure you understand how much having to deal with such a nuisance makes the Kindle even more sweet to my eyes.

Sony’s example is probably the most visible example of this trend, as Kevin Mitnick points out.

I lost count of all the Sony attacks. CORRECTED: Sony Scoreboard: Hackers 12, Sony 0, Source: http://tinyurl.com/6dcugje

—
Kevin Mitnick (@kevinmitnick) June 05, 2011

But they are not the only ones: the attacks on Citigroup and security company RSA are even more alarming. If even those companies that should be dealing with security issues every day are not impenetrable, chances are everyone’s data is at risk. Or, at least, that’s the message that most of the newspapers appear to be conveying.

While it’s easy to dismiss those people as fools, those facts should teach us something different: there is no such thing as a secure system.

As Bruce Schneier wrote in this afterword to Little Brother,

[...] it’s impossible to prove that something is secure. All you can do is try to break it. — if you fail, you know that it’s secure enough to keep you out, but what about someone who’s smarter than you? Anyone can design a security system so strong he himself can’t break it.

In addition to that, any organization that has to deal with security on the Internet, has to deal with two additional additional factors: numbers and skill.

The number of people and the resources they can invest on building, securing and testing their systems are and will always be lesser than what some communities will be able to assemble.

And even if they have a team of 50 full-time employees working on their security infrastructure, it is not unlikely that some kid some day, by dedicating 15 hours per day to his passion for security systems, will be able to devise a way to penetrate a remote system.

So, should we just do what we can and hope for the best? I don’t think so, but we should probably invest more time than we do now to handle the possible consequences of our systems being compromised (e.g. partitioning critical data, early breach detection, faster recovery). Again, we should prepare to deal with the fact that our systems may fail.

Again, we often spend a lot of effort trying to make our systems as hard as possible to break in, but we neglect to take the proper measures to make sure that, whenever that happens, we are able to contain damage and be rapidly up & running right afterwards.

Why else would it have taken so long for Sony’s to reopen the PlayStation Store (almost 1 month)?

Being a concept developed in the Open Source world, it is no wonder that distributed revision control systems give their best in that context. There are many pros and cons, that other people described in detail better than I can do. Of all the features they offer, however, the one I prefer is the least technical one, and it is related to the way they encourage new developers to contribute to open source projects. In that perspective, git and mercurial are a lot more effective than svn, for example.

It all comes as a side effect of authors and committers being two different roles. This can encourage new contributors, who are approaching a new project for the first time, and individuals who may not have the time and energy to dedicate long periods of their time to a project, but may be able to contribute with just a few patches.

How GitHub displays both the author and the committer of a single change. Oh, and yes, there is something wrong with the dates.

Think about that. Recognition is one of the most important drivers for Open Source contributors but, unfortunately, centralized revision control (subversion, CVS and the like) doesn’t help in giving credit to newcomers or occasional contributors.

That’s because, generally, sending a single patch (or even a few of them) is not enough to be granted commit access to a project repository (and rightly so) and the commit itself must be done by a project member with enough privileges.

With svn or cvs, the committer of a changeset figures as its author, and the original author of the code is often just mentioned in the notes or in some “credits” list.

With git or mercurial, on the other hand, the author and the committer of a changeset are not necessarily the same person: each commit can then retain the original author name.

I believe that some coders would be much more willing to contribute to Open Source software if they know their name will be included in the official commit logs, especially given the existence of sites like Ohloh, that track contributions by single commits. I would be much more willing to engage in a project if I knew that my changes would be attributed to me no matter who commits them.

That is why I believe what I said in the title: if you are about to start a new Open Source project, you should pick git or mercurial as your revision control system. Do it not just because they are better (and I strongly believe they are), but also because they will make it easier for you to credit any contributor you’ll get.

For those of you who are unfamiliar with the whole concept of distributed revision control, I suggest you to visit hginit.com or gitref.org, they both offer intuitive and effective tutorials about the benefits of using mercurial or git.

We usually tend to dismiss failure events as random, unlikely and sporadic. And, often, we are proven wrong.

Systems do fail indeed. Moreover, when something goes wrong, either it’s barely noticeable, or it leads to extreme consequences. Take the example of the recent AWS outage: everything was caused by a mistake during a routine network change.

Right now, some days after the event, post-mortem analyses and survival stories count in the dozens. There is one recurring lesson that can be learned from what happened.

Not only we should try to prevent failure, but we should design our systems to deal with failure as if it were systematic. This is the only way to build robust and resilient software, and still it may not be enough.
Most of the sites and applications that were able to stay up and running while others were taken offline were designed with that principle in mind.

Netflix’s example is probably the most significant: while they were affected by the outage, things looked quite calm from a customer’s perspective. In retrospect, it’s not surprising at all, given what they wrote on their Tech Blog:

We’ve sometimes referred to the Netflix software architecture in AWS as our Rambo Architecture. Each system has to be able to succeed, no matter what, even all on its own. We’re designing each distributed system to expect and tolerate failure from other systems on which it depends.
[...]
One of the first systems our engineers built in AWS is called the Chaos Monkey. The Chaos Monkey’s job is to randomly kill instances and services within our architecture. If we aren’t constantly testing our ability to succeed despite failure, then it isn’t likely to work when it matters most – in the event of an unexpected outage.

Even though Amazon explicitly encourages developers to build their applications to deal with random failures or service degradations, the guys at Netflix went out of their way to make sure they were not dismissing that kind of issues as unlikely. It’s good to know that this approach eventually paid off, and even if we’re often not in the position to adopt such radical strategies, we should certainly keep in mind the lessons they have learned.

It’s time to stop making fun of Murphy’s law, and start designing our stuff according to it. Stuff breaks, and when it happens, it breaks badly.

Since I was working on an application that uses Facebook’s and Amazon’s APIs and I was working offline, I often found myself unable to test the code I was writing against live data.

I must confess I struggled at the beginning.

I had no chance to try out my small application while I was working on it and, generally, I had to code during 1-hour trips, waiting until I got to work/home to see whether everything was performing as expected.

The outcome? I was surprisingly productive. And I’m sure it was not just because of the absence of common distraction sources (IMs, Email, Twitter and the like).

So, what made the difference? Here are some of the insights I got from the experience.

Write shorter and cleaner code & write for reuse: two long-time classics, they are even more important in this kind of scenario. Minimizing code means you have less stuff that can break, while maximizing reuse means you can rely on a lot of tested and stable code, focusing on the feature you are building.

Think before coding anything: getting it right the first time is significantly more effective than going through multiple rounds of debugging. While I was used to this when I started this career, this habit was getting weaker over time.
Working with fast development machines and powerful IDEs was slowly changing my approach to an iteration of the same sequence: code → test → debug. Working offline forced me to keep a clear picture of what I was trying to accomplish and think thoroughly before writing anything.

Write more accurate unit tests: I was forced to think about everything that could possibly go wrong with my code. Unit tests were the only significant way to test my code while I had no access to live data.

Be feature oriented (this is my favourite): since I had to work for a while without being able to perform a significant integration test, I tried to pack features into 1-hour slots, so that I could test one single feature each time I got online again. Also, if my app started misbehaving, it was easy to track the culprit.

Switch to a peer to peer SCM (mercurial, at the time): this granted me the possibility to bring the entire project history with me, commit local changes (again, grouped by feature) while still allowing me to sync my source code across my different machines.

What then?
As usual, I wouldn’t learn so much if I didn’t have so much to learn. While none of these points is certainly new by itself, what’s relevant to me is that this kind of experience taught me a lot of good habits and strengthened some others all in the same time. Not only I learned to cope with the disadvantage of being offline, but I even got better as a consequence.

UPDATE: a friend pointed out to this excellent post by Robin Wilson which expresses a similar opinion. If you liked this post, you might be interested in his one as well.