In this space, we’ll talk about all things tech. Whenever you are studying through any of our software – be it the Learning Tracker, the GREedge toolbar, the mobile wordlist, whenever your personal coach analyzes your performance and gives you feedback, whenever authors create your lessons and tests… the underlying technology delivers these fantastic learning experiences for you.
It is developed by the Research & Development team at GREedge and this the space is where we rant, rave, hypothesize, vent, joke and otherwise share our experiences on technology. (And while software or algorithms may not be asked on the GRE General Exam, you just might work on these at graduate school or in your career!)
Many software developers tend to think that only logical bugs are bugs worth fixing, and usability problems are not even worth a discussion, leave alone fixing. Let me ask you this: Ever found yourself resizing mySQL columns after running every query? Ever wished you didn’t have to do that every single time and that mySQL would please please auto-resize instead?
Well, this is a known “bug” (the developers might even call it a “feature”). Technically, it is not a logical bug, but a usability bug. It’s been around for years now – you can see the conversation thread here: http://bugs.mysql.com/bug.php?id=13760
Now the interesting this is that lots of people want this bug fixed, but the mySQL developers don’t bother to change it. Listen to a couple of mySQL users venting their frustration below:
[18 Jun 2008 17:27] Harald Groven This bug/feature is one of the two reasons that makes me prefer PhpMyAdmin to Mysql Query Browser. HTML-tables auto fits and autowraps nicely. The other reason is the lack access to an easlily accessible table of table metadata.
[5 Mar 2009 5:35] Howard Bayne I came here looking for an answer to this issue and instead I found out it’s a known issue that’s been on the table for over three years. It seems the developers and the users of this tool have differing views on usability. 
[18 Mar 2009 17:30] Andrew Roe This is honestly a real nuisance. As developeres and DBAs, we are in the business of streamlining diagnostic processes wherever possible and the lack of response to this all too common request this is highly frustrating.
This mySQL bug was just one example. There are many such bugs in lots of software and languages meant to be used by developers.
Now the point I’m trying to make is this: Just like we who write software feel frustrated when some tool or api we use is buggy, those who use our software (students, SFAs, lesson developers and others) will feel equally frustrated when they use buggy tools. At least mySQL developers have the excuse that their code is open source and their users are also developers, so their users are welcome to roll up their sleeves and fix the bug. But it’s a poor excuse and anyway we don’t have that excuse.
Now, in our R&D labs, if we don’t like the tools we use, we change them, right? We switch from one platform to another, one tool to another, one language to another. Our users have similar choices too – there lots of content authoring and grading tools, CRM apps, etc. But there’s NOTHING out there like the potent combination of what we have, we believe in the quality and power of our learning platform. So, instead of being complacent, we got to roll up our sleeves and start fixing all the issues there are, according to the user pain threshold they cause.
Summary: A bug doesn’t have to produce wrong results for it to be “worth fixing”. There are lots of software out there that crunch the numbers right or do whatever else they’re supposed to do, but only a few of them become popular and appreciated. Why so? It’s because they reduce the user’s pain. Many users may not even be able to articulate their difficulty. But we got to understand their language if we want them to use and derive value from what we write.
So, always strive to fix irritating and painful bugs quickly. It might not seem like a bug to you as a developer. But to the user, it is a bug, even if they can’t articulate it or propose a fix. To rephrase Gertrude Stein, a bug is a bug is a bug.
And dear users, if you happen to be reading this, and if there are some bugs on the Learning Tracker or the GREedge Toolbar or any of our other software that annoy you, please write to me at webteam@vepl.com. We know there are pain points and bugs lurking in there and we are working on them. That’s part of our job, to provide you better learning experiences and we love what we do!
