George Sudarkoff

There is no Bug

[Angry rant alert!]

Author of the blog "Hyper Agile Thinking" (oy vey!) in his article "There is no Bug. It is not the Bug that Bends, it is Only Yourself" argues that:

Only when you realize that “there is no bug”, that the problem lies within, can you change your behavior (process) such that no bug is reported on the software that you deliver. I’m not saying that real software with zero bugs is an attainable goal, only that you consider a change of perspective in order to bend the spoon a bit.

...The problems lie within. Only when we acknowledge this and accept it can we hope to affect real change. Agile development is an excellent platform for seamlessly incorporating the required introspection and continual improvement.

Oh, there's no bug, you bet! But behind all those big words you are missing another important problem - there is no program and there is no process either. It is all an illusion (if you follow the original logic of "there's no spoon")! So, while I wholeheartedly agree that it is more accurate to treat bugs like something internal (and really, let's call them defects already?), it doesn't really change anything. Because bugs only "appear" when internal reality collides with external and there is nothing you can do about it. Agile or not, you still have to go outside and test your theories on the harsh real world. You know, by actually giving your shit to people and hoping nothing explodes.

And while I am at it, don't you think that "agile methodology" is an oxymoron?!

Installing SCons on Leopard

In case you were wondering, here's how you would install SCons on Mac OS X 10.5 (Leopard):


$ su -
$ curl -O http://prdownloads.sourceforge.net/scons/scons-0.97.tar.gz
$ tar zxvf scons-0.97.tar.gz
$ cd scons-0.97
$ python setup.py install --prefix=/System/Library/Frameworks/Python.framework/Versions/Current
$ for i in /System/Library/Frameworks/Python.framework/Versions/Current/bin/scons*; do ln -s $i /usr/local/bin/`basename $i`; done
$ exit


Build numbers

Wincent Colaiuta in his blog post "Build numbers in a Git-based development cycle" is trying to come up with the build numbering scheme. His requirements are that the build number (1) uniquely identifies  the revision of the source code used in the build and (2) provides a clear distinction between earlier and later builds (i.e. is sequential). Git is a distributed system and as such instead of a sequential revision number it uses sha1 to uniquely identify individual commits. The problem is, sha1 is quite long (even its abbreviated form is seven characters) and absolutely non-sequential.

I myself just converted all my repositories to git. But my build numbering scheme accommodates new environment just fine, so I wanted to share. First of all, why do you want the build number to be sequential? So that your users could tell which build they have installed on their system and whether or not it is the latest one. Second, why do you want the build number to uniquely identify the sources? So that you (the developer) could pinpoint the sources that were used to make the build (in order to find the change that introduces the bug, for example).

This divides the problem into two distinct parts and I decided to address them separately. That is, my build number has two components: a sequential number for the user and a unique source code identifier for myself. The former is just a number automatically incremented by the build infrastructure while the latter is the abbreviated sha1 of the latest commit in the repository used by the infrastructure to produce the build. Theoretically, I can have two builds made from the same revision, but in reality my build infrastructure is smart enough to avoid doing unnecessary work. That means, that although the full build number might look quite intimidating (e.g.: 4ef.7e93fcd) the first part of the number is always sufficient to uniquely identify the build. And in fact, the second part is almost never directly communicated to the user.

Additionally, I never number my developer's builds (builds created from my working tree). It is not only unnecessary, but actually quite undesirable. The reason? It would be a bad idea to distribute a build made from uncommitted changes and I want to make sure that the developer's builds are easily recognizable as such (e.g.: 0.0000000). All this makes it very easy to implement a script that automatically increments the sequential part of the build number and stick the abbreviated sha1 to it to form the complete build number.

Bye-bye svn! Hello there, you sexy git!

I can't believe I am doing it! But after playing with git for a couple of weeks (including using it on top of Perforce at work) I am converting all my svn repositories to git. It is a completely different experience. It takes some getting used to, but when you finally do, it's like finding a Jesus. The feeling is very similar to what I experienced after switching to Mac. The stuff just works!

Pure means impractical?

The other day, a friend of mine complained about Smalltalk being responsible for his increased rent. I responded that to me Smalltalk always was a little bit like Latin and that although learning Latin helps in understanding the structure of other western languages, nobody expects you to actually speak Latin. (I know it doesn't make much sense here, so please go read his post.) This lead me to further thinking about things that are sound in theory but not very useful in practice. There seems to be some connection between "pure" and "impractical", don't you think?

In one of my previous posts I argued that software systems are essentially incomplete. I thought it was an interesting argument against obsessing about completeness. But of course in reality software systems are far from formal (pure). Unlike calculus, software systems are not necessarily constrained by any formal set of rules of inference (heuristic and evolutionary algorithms come to mind). Same is true about programming languages. In fact, maybe this "impurity" is precisely why programming languages like C++ are so useful?

TextMate to go Leopard-only

The blogosphere is abuzz over Allan Odgaard's announcement that most likely TextMate 2.0 will be Leopard-only. Everyone and their monkey has an opinion. I promise mine will be short and irrelevant.

Allan says that 90% of his users are early adopters. He says that the upgrade is free so he will not be losing any money by abandoning the remaining 10%. Also, by going Leopard-only he will be able to simplify the code, make it more robust by using garbage collection and whatnot, and overall make it worthwhile for those that do upgrade.

As a software developer I can totally understand his move. It is no fun to support legacy crap -- the shiny new things that Leopard offers are not only tastier to chew on, they also make our code prettier (and prettier means better in all practical terms). Every single argument is logically sound and makes me nod in agreement. Too bad the situation has nothing to do with logic.

The people using your software have rights (even if they didn't pay for the software). Of course, it is the kind of right that they cannot defend in court. But users believe in those rights and that is all that matters. It is not even about fairness -- it's about feelings and feelings will be hurt. Users will retaliate and you better be damn sure your brand is capable of sustaining the punch.

That said, I do believe that now is the best time to piss off a few users in favor of the long-term benefits. Come on, it's 2.0 we are talking about, we all know that it takes three major releases for any software to mature. Even Allan tells us that his users are early adopters. It means that he is yet to cross the chasm of obscurity. And why not take the advantage of the situation and shed some weight in preparation for the leap?

So, does Allan have the right to abandon 10% of his users? Hell yeah! Do users have the right to complain? Hell yeah! Is it going to work out just fine? We shall live and see.

Snipplr

Snipplr - Code 2.0

This is a brilliant service, thank you, Tyler! With the immediate support for TextMate and WordPress and an open API so that others could integrate it into their own tools - it's a killer application!

Some king of line-by-line code-reviewing/commenting/rating feature to help the community improve the quality of the code would be nice. But I am sure Tyler has plenty of his own ideas on how to improve the service further.