Many times on the boards someone has reported an issue and we’ve mentioned that it’s a “known bug” and that we’re working on it.  But what is a bug?  A bug is a “glitch in the system” – basically something that sneaked through that causes Helium to behave as it shouldn’t.  But how does this happen?  Are we developers sneaking in easter eggs just to mess with you?  Yes, totally.

I’m kidding.  In actuality what you see on Helium is an oversimplification of what is actually going on.  Helium is actually thousands of lines of code and thousands of specifications – all dictating how it’s supposed to behave.  With each new release both grow and with them the complexity of Helium as well.  To combat this we build a test suite that checks that Helium is still following all the “rules” (specifications) which we run every time we check in some new code.  Even so, stuff slips through.  Interactions you can’t foresee happen.

So next we have our QA/Ops team.  With each new release or fix we deliver a “release candidate” that they dig through making sure not only does it do all the new things it’s supposed to but also that all the old stuff is still there and functioning.  For every bug that you see on live they find hundreds (thousands) that we fix before you ever see the new release.

However, no matter how well you know an application they (and us in development) are only a handful of people.  We can’t imagine all the ways the thousands of Helium users will test and use the site.  What they’ll do that we’d never think of.  And, more importantly, how the new users will approach the site – as familiarity sometimes causes blind spots.  So, inevitably, we release the new build to the live servers and our community does something we never even thought of and poof we find a new bug.

This is just a natural part of development.  Honestly, with the size of our code (massive) and the size of our development/ops team (very small) it’s amazing that we are able to release so much new code and not have more bugs slip through.  What you might also not realize is that Helium is actually not one code base but over a dozen all interacting in interesting ways – with each new code base added to the mix exponentially increasing the complexity of the final entity.  Some are also built in different languages or in different frameworks – with each being a combination of user interface code, middleware code, and database code which have to coexist and interact.  In other words, the simple site you see is an extremely complex co-mingling of various code bases, languages, specifications and interactions – all of which breed the opportunity for bugs to arise.

Or we really are just messing with you and testing to see if you’ll notice.

I hope this helps.

So you’re scooting along with Helium and all of a sudden something happens and your experience comes to a crashing halt – what do you do?

Bugs are an unfortunate part of any computer program – whether desktop based like Windows or web based like Helium.  As programs grow they become more and more complex and it’s simply a fact of life that programmers are human, they make mistakes (even the best ones), and things go wrong.

We run all our new code through a process – called Quality Assurance (QA for short) – which finds many bugs, errors and issues that we fix before we ever release it to you, the Helium community.  This is after normal testing by the developer of their own code to make sure it performs as they expect.  However, it’s inevitable something gets through.  Sometimes you might not even notice it or it’s trivial – some font is 12 px in IE but 11px in Firefox, etc – but sometimes it’s to the point where Helium – or a part of it – becomes unusable to you.

So what do you do?

Simple.  You want to file what is called a bug report.  Ideally, you do this at help [at] helium dot com.  However, don’t just tell us “X is broken” – we need a little more help than that.  It’s not that we’re trying to be difficult or saying there is not a problem – it’s simply that we need enough information so that we can recreate problem – which is the first step in narrowing down what the issue is so that we know how to fix it.

So, in the e-mail, please include answers to the following questions:

  1. What operating system are you using?
    • XP or Vista is very useful, but even Mac or Windows (or Linux?) helps.
  2. What browser are you using?
    • This one is very important.  Internet Explorer, Firefox, Safari, Opera?  Which version?  For example, IE6 behaves vastly different than IE7.  Same with FF2 and FF3.  Typically you can find this information by selecting either “File” or “Help” in the top of the browser and clicking “About [browser name]”
  3. Do you have any extensions active?
    • This is mostly dealing with Firefox – although others like IE7 allow this as well.  Are you using Ad Blocker?  Firebug?  Do you have no idea what this means? (meaning likely you’re using the browser default)  We have found some extensions that don’t play nice with our features.
  4. What were the steps you took to get to where you found the error?
    • “I was trying to write an article…” – ok.  From a “write now” link or via leapfrog?  Did you copy and paste from another program?  Did you eat your Wheaties this morning? (kidding)
  5. What exactly is the issue? (be detailed)
    • i.e. “It won’t submit, it just shows the whirring icon”, “It refreshes the page and I lose my work”, or “My computer exploded and my dog soiled himself.” (kidding again on the last one)

Most importantly, again, bear with us.  We’re trying to help and I know that when you get an issue the last thing you want to do is answer 20 questions – you want it fixed and you want it fixed now.  We do too.  The simple fact of computer programs is that there are so many different factors – different hardware, operating systems, internet connections, etc – that a million things can go wrong. (much of the reason why console gaming has basically replaced computer gaming – one hardware and software configuration)

I hope this helps.