I am pretty selfish. I would like to think I can be wholly altruistic, but I cannot remember a deed I did for someone else where I was not rewarded by a general feeling of well-being. Perhaps this is normal and we kid ourselves that true altruism exists because, well, it feels good to believe that. Recently, I realised it is because of this feeling that I volunteer as part of the local developer community.

I have been involved in the Ann Arbor area developer community for just under five years. A couple of colleagues had suggested I attend an Ann Arbor .NET Developer (AADND) meeting, but oddly, a woodworking class is what led me there. In that class, I met fellow developer Steve Meagher, we became friends, and he eventually persuaded me to tag along with him to a .NET meeting. Like many within the developer community, I avoided user groups and other community events for fear of not fitting in or some other perceived discomfort. At that first meeting, I met David Giard as he was the speaker that evening. Meeting David turned out to be a gateway into the wider community and volunteering. At the time, he was the president of the Great Lakes Area .NET group (GANG) and he invited me to attend a meeting there the following week. Just as with Steve at woodworking class, another connection was made and so it was that my adventures in the developer community continued. Through the friends I made attending the local groups, I ventured to far off places like CodeMash and Kalamazoo X. Through the friends I made attending those far off places, I ventured to electronic wonderlands like Twitter, StackOverflow, and my own blog. And eventually, through the encouragement I received from this amazingly supportive community, my family, and my friends, I found the courage to look inward, to seek help for the demons that fostered my low self-esteem, and to grow.

I have volunteered on the board of AADND, as a participant and team leader at Give Camp, and as a speaker at CodeMash; having thoroughly enjoyed every second, I can tell you that volunteering is 100% pure fun.

OK, that is utter bollocks; volunteering is hard. There is no pleasure in finding content for newsletters and slide decks, no joy in the conflicts a team faces when you have less than a day to get a database migrated, no comfort in preparing and rehearsing a talk1. Volunteering is often stressful, sometimes boring, and always built upon a foundation of compromise and sacrifice. If those things were the rewards of volunteering, I cannot imagine anyone who would do it. Every year, Michael Eaton tells a tale of how he declares that this Kalamazoo X will be his last. That it is too much work. Too much worry. Too much sacrifice.

Thankfully, the hard work leads to gratitude: the emotional words of a non-profit director overwhelmed by the generosity of local developers; a room of people applauding at the end of a talk; or a simple "thank you". Regardless of its delivery, seeing or hearing that someone is grateful makes all the effort worthwhile. It feels good. For community volunteers like Michael Eaton it is the gratitude shown by attendees, speakers, and co-organizers that ultimately leads to more events (like just one more Kalamazoo X).

So, next time you enjoy something that someone volunteered to do, show your gratitude. And if the opportunity arises, try volunteering; you have no idea who might be grateful and how good that might feel.

  1. or a last minute Pecha Kucha that your friends then make sure will get heard while you are busy searching for that lost sleep 

Why software bugs exist and how you can help

Numbers in software development are represented by fixed size variables represented in binary. These are usually 8, 16, 32 or 64 bits (each bit represents a 1 or a 0). When we develop software, we choose which of these will provide enough space for the thing we are representing.

Recently, the Gangnam Style video on YouTube surpassed 2,147,483,647 views and it appeared as though the view counter broke. That number is significant because it is the upper limit of a 32-bit signed integer. It turns out that the video view count was being represented using a 32-bit signed integer — a signed value1 can represent whole numbers in the range -2,147,483,648 through 2,147,483,647; it cannot represent any number outside that range.

Though, according to YouTube, this turned out to be an Easter egg2, the bug was there before they updated the counter to 64-bit and it certainly is not the first time a number has pushed the limits. For example, the use of two digits to represent a year that contributed to the infamous fizzle that was Y2K.

But why? Why are there bugs at all?

Although it may seem like software bugs are there just to ruin your day, they were not intentionally put there or maliciously inserted to give you a reason to "Office Space" your device. As software engineers we have to consider a variety of constraints on the software we are developing. How much space does it need to run? How much space will there be on the device on which it is to run? How fast does it have to be?  How many years will the software be in use3? What other software will be running? And we have deadlines by which our work has to be completed. In fact, software engineers tend to consider a whole host of things such as the requirements of the software (functional, spatial, and temporal4), the specification of the system on which it is to execute, project deadlines and budgets, and the expectations of the end user.

Almost always, there has to be compromise. Even though a solution might be possible that accommodates all considerations, we have to deliver software in a time frame that people will pay for and some things just take too long or cost too much. That is not to say that all software bugs are because of time and money, some exist because of mistakes and as a consequence of poor design.

What does it all mean?

Software engineers like myself do not want you to encounter bugs. We work very hard and the QA teams work very hard to ensure that you do not get buggy software; if we see a problem, we do what we can to address it. To find these bugs, we try to consider all the ways our software might be used and test them. Unfortunately, most bugs do not advertise their existence quite so obviously or politely as YouTube's view counter bug. For example, when in comes to the infinite ways any one device might be configured with different peripherals and apps installed, we just cannot test them all; the system is too complex5.

 Good developers welcome user feedback. We need your help.

Next time you encounter a bug in the software you use, whether it is a mobile app, a website, an ATM, a desktop application, or some other device, spare a thought for the software engineers. Remember, good developers welcome user feedback. Take a moment to tell them or the publishers of the software about the problem.

  • What did you type, touch, or click?
  • What else was running on your device?
  • What part of the software were you in?
  • What Internet browser or operating system were you running?
  • What versions?

Be as detailed as you can. All these details and more can help a software engineer track down, reproduce and ultimately fix that bug.

There is no malice in a software bug. It was not put there specifically to ruin your day. However, without your help, it will not go away. So, reach out to the developers and tell them, they will thank you for it.

Today's featured image is based on Software Bugs by Martin Maciaszek.

  1. signed means it can be positive or negative 

  2. An Easter Egg is a hidden feature often added to software as an amusement for users who find it. Examples include the "barrel roll" in Google or the flight simulator in Excel 

  3. Underestimation of this was a big contributor to Y2K 

  4. i.e. how it works, what space it needs, and how long it takes to run and for how long it has to run 

  5. That's a discussion for another time