Cynical Software

Cynical Software

[linkstandalone]

While I was still in school I had the opportunity(?) to participate in a hackathon. For those unfamiliar (and to pad my word count), a hackathon is a coding competition where you or a small team produce some software that is then judged by some people who judge software. Some of these have themes, and some do not, and the one that I was in did not. My team decided that we would address what we perceived as an issue in the IT / System Administration world, namely bloated ticketing tools. We brainstormed the problem and eventually came to the conclusion that the issue with most ticketing software is not the main feature, i.e. ticketing, but the clunky GUI that comes along for the ride. We deduced that the GUI is not made for the sysadmin or programmer or what have you, but the managers and admin staff, people who want to make sure the code monkeys are working. However, the GUI tends to lead to an anti-pattern, where a programmer or sysadmin spends most of there time hopping around in shells, or IDE's, but then having to spend more time logging their actions in the GUI. We decided that to fix this, we would right a lightweight shell utility, that could exist on any machine, and log tickets to the ticket service database, and the clicky-clacky GUI could see them. Thus Terminal Ticket was born. It targeted JIRA, since it is very widely used. We built the thing, and came up with a demo and... Came in dead last.



Now, there are a few reasons for this (other entries were way better, we were all first timers, etc), but the one that I want to focus on today is the fact that it was not cynical enough.

By cynical, I mean the school philosophy, the one the OG mad lad Diogenes was a student of. Cynicism al la Diogenes is the rejection of all things unnecessary in life. Diogenes was an extreme example, living in a barrel in the market, urinating in the street, and allegedly throwing away his only bowl after seeing a small boy drinking from his hands. Our software was not cynical and did a lot of unnecessary things. For one thing, we wrote it python, allegedly to "speed development" which, in a way it did because it allowed us to develop a lot of junk in a short amount of time. Python carries a large amount of extras that must be bundled onto a system, so there goes our lightweight requirement. Python is also pretty slow, not GUI slow but still slow in terms of shell, and this was on top of api access, and a complicated configuration to plug into you enterprise's JIRA service and a hundred other things. It also did more than just opening and closing tickets, a lot more. All of this bloat made our presentation confusing at best, and only one judge really "got it."

So, we lost, but I refused to believe it. I railed against the Academic judges. I thought we had produced the next VIM, and that sysadmins everywhere would bow before our superior product. So I made a kick starter, and made 1 dollar. Then I finally gave up, and left it alone for awhile. But it stayed in the back of my mind. It was not until I read this article, from Suckless Software's website, that my eyes were opened. I felt like Diogenes must have upon seeing the child drinking from his hands. "What a fool I am!" I exclaimed, as I beheld the majesty of the erlang ticket system. One command, everything tracked through git, it was beautiful, it was pure genius. I realized the flaw in Terminal Ticket was that we did too much that was unnecessary. We were not geniuses, we were falling to the enterprise trap of doing everything, and the judges could see it. What we had made was a sucky piece of junk that was only "minimal" because it was on the command line.

The cynics sought to remove unnecessary aspects of life, and to live without them. We thought we were removing unnecessary bloat, because we were working around the GUI. In reality, all we did was drag all the bloat into a command line interface, and it was confusing and slow. In reality, we should have been more cynical and focused on only the feature we needed, instead of trying to integrate every feature of the service we were using.

The point of this embarrassing tale of woe is that if you want to make truly suckless software, you have to be a cynic. Remove what is truly unnecessary, especially if it is handled by existing tools. Minimize, minimize, minimize. If you can not do that, then just opt to make something that sucks but looks flashy, because something that sucks but is pretending to minimal will be dropped in a heart beat by the people and programmers who know what they are doing. To round this story out, I am going to share that script I use to track time on personal projects. I developed it in the spirit of the Erlang Ticket system, although mine is only for a single dev, namely myself.


#!/bin/bash

DIR=$(pwd)
TOOLD="~/Projects/Python/ticket"
TFILE=$DIR/tickets
TEMPLATE=$TOOLD/template
TEMP="$TOOLD/.tmp"

open() {
	branch=$(git branch --show-current)
	git checkout ticket_tracking
	read -erp "Ticket Title: " title
	ticketnum=$(grep -o \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* tickets | wc -w)
	ticketnum=$(expr $ticketnum / 2)
	ticketnum=$(expr $ticketnum + 1)
	cat $TEMPLATE > $TEMP/tmp
	sed -i "s/&l tide >/$ticketnum/g" "$TEMP/tmp" 
	sed -i "s/< title >/$title/g" "$TEMP/tmp" 
	$EDITOR $TEMP/tmp
	cat $TEMP/tmp > > $TFILE 
	rm $TEMP/*

	git add $TFILE
	git commit -m "Added new ticket with id $ticketnum and title $title"
	git push origin ticket_tracking
	git checkout  $branch
}

open

					

That is it. I run this when I start a new task, and when I finish, I open the ticket file, mark the corresponding ticket number as i closed and commit it to the tracking branch. Then I can easily used the commit history on that branch to track time on each task. It it simple elegant, and fit's in very well with my current work flow. Would it work for anyone else? Probably not. But the point is not for it to be useful to everyone, it's to make my life better, and reduce unnecessary work.