Bug vs feature

We’ve had a lot of discussions about what should go as a “bug” and what should be a “feature” in our tracker. Turns out there’s quite a big gray zone here.

Example: a website has a table with AJAX-based pagination. Navigating to an entry detail and clicking “back” doesn’t bring you to the same page of the table.

The project manager considered it a bug – “back” doesn’t really go back, so the navigation is broken and it’s a serious user experience problem.

The developer, however, knew that the way to have that working is to assign a unique URL to each page of the table and use the history API to update the URL in the browser upon navigation, so that the back button really goes back.

Nothing was essentially broken within the code, nothing needed a proper “bugfix” or “debugging”; the way forward was to do some maintenance and introduce a new piece of technology to the UI. Doesn’t that sound more like a feature than a bug?

It’s a communication problem; a typical situation where mixing abstraction levels causes confusion. From the product perspective, it’s a clear bug – the behaviour is different from expected and causes some kind of harm to the user. But when you wear the technical hat, you see that the action steps don’t resemble bugfixing as understood by programmers.

Another real life case: We installed Raven.js to be notified about Javascript errors throughout our site. But our scripts are concatenated and minified on production, so the tracebacks we see in Sentry aren’t readable. Action step: change the Javascript compression toolchain, replace the minifier with another one that happens to support source maps and configure Sentry to read them properly. Bug or feature? Technically, again – it’s nowhere near bugfixing.


There’s two distinct pieces to information to each issue: what is it about (new feature? system behaviour other than expected?) and what are the action steps to fix it (write code? debug? change your infrastructure? all of them?). The proper question to ask here is: Which of these would be useful for issue taxonomy?

I ended up deciding that it’s the project perspective that matters – if there’s a problem that is hurtful to the product, it should get priority regardless of the fix being coding, debugging, refactoring or changing some colours.

It’s also noteworthy that “bugfix vs feature” is not a dichotomy – a lot of issues don’t fit here, like design and maintenance activities, so there’s still plenty of space to invent some taxonomy.

Commentary on Javascript: The Good Parts

“The Good Parts” has been a good read. The language has been described briefly and consistently from ground up, including a thorough explanation of objects, functions, closures and arrays. A great addition to the mix is a description of the numerous pitfalls and design problems. It seems opinionated at some points (more on this later), but very valuable as a whole. (That’s correct – “The Good Parts” actually has two appendices dedicated to the not-really-good ones.)

My commentary for selected parts of the book follows.

Read On…

Interfaces dissected

Recall methods. A method is some piece of code that can be “called on objects”. There are two things to methods: They’re meaningful with an object to call on, and their interface looks like “they can be called with some arguments to return a value”.

Properties are similar to methods, in that a property is meaningful when paired with an object. They have a different interface than methods, though: you don’t “call” them; instead you “get” and “set” their “current value”.

We normally consider properties and methods to be some abstract “traits” of objects. But why not treat them as first-class objects too? Imagine properties and methods as building blocks for object interfaces. A method would be an object that describes callable parts of other objects, while a property describes readable and assignable parts.

Read On…

Introducing Glory

Glory is the code name of my prototype IDE for developing OpenGL-powered graphical effects. After half a year of work, it has entered a functional alpha stage (and awarded me the MSc.)

screen1

Read On…

Say hello to Unicode

Basic explanations

Unicode is a standard that defines several things. Here is a handful of some most important facts about it:

  • There are thousands of “code points” that represent characters in various alphabets, numbers, punctuation, various symbols, etc. Each of these has a name and a number. Here are some examples:
    • LATIN CAPITAL LETTER A
    • LATIN SMALL LETTER C WITH ACUTE
    • DIGIT SEVEN
    • MINUS SIGN
    • SUPERSCRIPT TWO
    • RIGHTWARDS ARROW
    • BLACK CHESS ROOK
  • Different code points may share their appearance, or “glyph” (like OHM SIGN and GREEK CAPITAL LETTER OMEGA).
  • Code points are grouped into blocks like “Basic Latin” or “Mathematial Operators”. They also are divided into categories like “Letter, Uppercase”.
  • There are some “encodings” that provide a mapping between code points and their bitwise representation. The encodings have names like UTF-8, UTF-7 or UTF-32. Each of these has some interesting properties.
    Read On…

Git adventures: Loose object is corrupted

I couldn’t read my Git history today because I ran into this problem:

$ git log --oneline
f1330fd Basic automation
7234c6e Textures work
3b18493 Fix combo defaults
error: inflate: data stream error (incorrect data check)
fatal: loose object 65d626bb82c8996f8fc5f659f7c207fee1d74948 (stored in .git/objects/65/d626bb82c8996f8fc5f659f7c207fee1d74948) is corrupted

The same message appeared when checking the repository with git fsck.

My working copy and dozens of last commits were intact; this error showed up when trying to view more history or when trying to clone a repo. Some googling revealed that I should get the original (non-corrupted) object from somewhere and replace it.

Read On…

5 ways to use Python with native code

So you want to make a project with the advantages of native code. You like the performance of fine-tuned C, you need some heavy pointer juggling or bit fiddling or SSE, or perhaps you just dream of the vast lands of C libraries available around there. But you’re in love with Python and really want to be able to glue your app together with elegant high-level code. Hard decision? Definitely.

But why can’t we have both? Using two languages together introduces complexity, but might have good payoffs for your project. Give it a shot.

Read On…

Closures: The cute pets that bite

A closure is basically a function that was defined in some local scope and has access to the local variables from that scope. Additionally when a closure (the function object) outlives the scope where the closed variables were defined, their lifetime gets extended (or not, depending on the language).

I find closures wildly useful, especially in prototyping. They also are welcome in production code, if you don’t get too carried away. However they are not exactly as intuitive as one might expect and if you decide to use them there’s a handful of details you must remember not to introduce bugs.

This article has two parts:

  • Differences between closures in some languages
  • Pitfalls related to closures that you should remember and avoid.

Also for a quick recap on closures see this gist.

Read On…

The Python Gets Gallery

Behaviour of Python objects can be customised in tons of ways using special functions. This article describes some of them, all confusingly starting with __get and all having drastically different purposes.

Read On…