Avian’s Blog

I recently came across the On the Phenomenon of Bullshit Jobs article. In it the author observes that technology has made it possible to produce goods with minimal manual labor, however work hours in general have not fallen accordingly. He attributes this to invention of pointless managerial jobs that seemingly don't contribute anything of value. I don't really subscribe to the notion that this was a conscious design by some entity to keep everyone nice and busy and submissive but the article does show western society in an interesting light (and the ensuing Hacker News discussion offers some better theories of how this situation came to be).

While this topic is fertile ground for pointing fingers at various middle managers and telephone sanitizers, I think a lot of such useless work is also done right here in the engineering community that is doing the said finger pointing.

Take for instance how a lot popular technologies in the mature part of the life cycle evolve. Once some product has reached a stable point where it solves a users' problem well enough and no one in the industry has any technological advantage, things often start going downhill. Manufacturers start adding useless superficial features, like adding "revolutionary" user interfaces, all in an futile attempt to be better than the competition. Think microwaves with elaborate functions no one every uses, "feature phones" from recent history with tons of useless fluff when everyone wanted to just use them to hear the voice on the other side, and so on.

The situation in the commercial software world is often similar, except the competing product is commonly its own older version. And with the forced upgrades, planned obsolescence and user's data held in ransom through incompatible formats the software world has even more leverage to force such useless changes on those users that find the older version fits their needs perfectly fine. As the most extreme example, see almost all changes in Microsoft Office beyond circa 1995.

In the commercial world it's easy to blame the ignorant management, greedy shareholders and anomalous market pressures for this situation. But it's baffling why similar things happen with free software projects that are mainly based on voluntary work. With recent Debian upgrade this has become most apparent. Projects that have reached the point where they more or less implemented all features one would want from them started implemented trivial changes that make no sense. I'll leave GNOME for some other flamewar, but take GIMP for example: the new version changes the semantics of windows versus application, replaces traditional sliders with something I have never seen before and shuffles around keyboard shortcuts. As far as my use of this software is concerned, there is no functional improvement and any benefits are completely offset by yanking my muscle memory from under me.

There seems to be some kind of a stigma attached to applications that stop having any visible changes. But I believe that for a mature application that does its job this is a good sign. Granted though that it's not easy to discern such a properly maintained project that only accepts an occasional bugfix from an abandoned one. Unix and GNU authors of old got this right though. You don't see sed renaming s command to r on a whim, but you do still see after all these years an odd bug fix release.

So to connect this back to the initial thought. It seems that there's a notion that even once you've arrived at something that genuinely works, you have to keep paddling in place, even though just maintaining the existing state with minimal effort would have better results for everyone involved. Someone with a social science background can now try to explain whether free software projects follow this because people bring in this habit from their day jobs or there is some other (market) pressure involved.

Anyway, from the technical standpoint I would just like to conclude by saying that please, acknowledge at some point that your project has reached everything that its users want to do with it and stick to bug fixes. Understand that the user interface is an interface. You don't randomly change mature APIs without a very good reason, do you? Rather than constantly trying to marginally improve it and making everyone miserable in the process, you can then use your remaining resources on starting something excitingly new from scratch.

When developing embedded software, having a working serial terminal emulator is almost as important as having a working C compiler. So when working with VESNA I more or less have at least one instance of CuteCom running on my desktop at all times.

While CuteCom does its thing relatively well, the last version released by the original author (0.22.0) has a few minor annoyances that only get bigger with daily use:

• Program occasionally stops saving terminal settings,
• device drop-down history starts accumulating empty lines and
• input widgets are not disabled when serial port is opened in read-only mode.

Fortunately, all of these can be fixed with more or less trivial patches. Unfortunately, there has been zero response to these patches from the upstream author. I have also tried to reach the author of the Debian package via e-mail to ask him if he might include these patches in the version shipped by Debian. It has been now more than a year since these attempts at communication and I have yet to receive any response.

So basically, now I'm just throwing the whole thing into the wind and hoping that maybe, just maybe, at one point someone important will pick it up and I won't have to keep installing a locally-compiled version of this package on every machine I use.

You can get the Debian source package and amd64 binary for Wheezy. If you want to include these fixes in some other distribution of CuteCom (gasp!) I have also been kind enough to nicely package them separately for you.

These days I use git almost exclusively for version management. Not just for code, but also sometimes for plain text or LaTeX documents. One thing that soon becomes apparent when using git for prose is that default command line tools are very bad at handling long lines. There are some workarounds that improve the situation somewhat, but you have to remember to apply them on a per-repository basis and don't solve all problems.

However, recently I noticed that this deficiency can also become a problem when handling code contributions and pull requests on GitHub.

Take for instance this example where you are merging in some changes from someone else's branch. git diff doesn't show any indication that something may be hidden beyond the right edge of the terminal:

A pull request on GitHub fares marginally better. Here you at least get a scroll bar at the bottom that hints at the fact that something may be amiss. However, if this branch would contain some more changes, the scroll bar could be several screen heights below the line that is causing it. Unless you have a mouse that can do horizontal scrolls it becomes practically impossible to review code like that (the view port is also conveniently set to fixed width, so resizing the browser window doesn't help).

To be honest, until yesterday I didn't even notice that you get a scroll bar.

Only opening the modified file in an editor that will automatically break long lines (and not all of them do that!) will unambiguously reveal the complete content of the pull request.

So I guess the conclusion would be to not accept pull requests from untrusted sources based solely on git diff output and be mindful of scroll bars on GitHub.