Why build it at all (TRS series part 1)¶

Tags: nelenschuurmans, django, trs

(“TRS”? “Time registration system”! An internal company website for managing our projects and for booking hours. I’ll use this blog series to simply tell you how I build it. With topics such as “bundling javascript”, “python 3” and “letting test coverage slip”.)

Ok, a time registration system. A bunch of Person objects in a database; projects you can book hours on; probably some assignment of persons to projects; a bit of reporting. Why build it yourself?!? There are 2538 existing ones! On the other hand, it is relatively simple, so it can’t hurt too much to build it yourself.

In the end, the assumption was that there are enough special cases to make it worthwhile.

• We’re a project organisation. Everything revolves around projects. All the work we do is within projects, most of them external (which means: paid by a customer). So we want to distinguish between internal and external. And which ones are subsidized projects, as they have some special rules. And some, like the internal “vacation” project, shouldn’t count towards some of the totals. Etc.

• As projects are the core, it makes sense to craft a beautiful, well-working customized app instead of taking some works-reasonable-but-only-that existing open source project. Something that costs money is out of the picture (even if building it internally costs 10x the money, but that’s one of our weirdnesses).

• We had an existing system: we needed to get the data out and into the new system. Getting it out of the old one is relatively straightforward (“requests” library, “beautifulsoup” and “import csv”). Getting it into the new system is way easier if that’s your own system, obviously :-)

• Coupling with our own user database (active directory).

• Custom metrics. Hours booked external versus internal (but not counting the vacation hours). Percentage of hours booked outside of the allotted time budget. Your turnover (hours per project times your tariff on those projects) this year. With a couple of special cases/rules in there, of course.

In the end, I was the one making the new system almost single-handedly. Fun! I had a personal reason to particulary enjoy building it: it was a relatively straightforward Django app. Lots of Python coding, quite some thinkwork to set up the data model, designing the user interface. All things I like.

Now, why was this particularly enjoyable? Well, as I was quite stressed at the time. I recognized it and took a little bit of time off, spending some afternoons cycling. And, to quote from a previous blog post:

And at about the same time I started an all-new internal project: a relatively straightforward internal Django timekeeping app. Lots of work and lots of tweaking, but at least a stressless productive programming assignment. Just coming up with a good architecture, a good css layout, some nice and proper code and yeah, I was happy again.

So… “therapeutic programming”? :-)