Tracking Time – The Daily WTF

Mihail was excited when, many years ago, he was invited to work for a local company. At the time, he was in college, so getting real-world experience (and a real-world paycheck) sounded great. It was a small company, with only a handful of developers.

The excitement didn’t last long, as Mihail quickly learned what the project was: parsing commit messages in source control and generating a report of how many hours a developer worked on any given task. It was a timesheet tracking application, but built on commit messages.

“This… seems like a bad idea?” Mihail told his supervisor. “Couldn’t we just do this in a timesheet tool? Or heck, a spreadsheet? Accounting would probably prefer a spreadsheet.”

“If we did that, people could edit their numbers,” the supervisor responded.

Apparently they hadn’t heard about amending commits. Or just… lying in the commit message?

Now, Mihail wasn’t allowed to start working. A design document needed to be crafted first. So several senior developers went into a room, and hammered out the design. Three weeks later, they had a basic structure of five classes: components, which were made up of milestones, which were made up of tickets, which had contributors, which made commits. It wasn’t a complicated design, so it was mystifying as to why it took three weeks to write. More problematic- the project had only budgeted a month, so Mihail was left with a single week for implementation.

One frantic week later, Mihail handed in his work. It was insufficiently tested, but more or less worked according to the design. He had to take a week off of work for exams, and when he returned from those exams, the senior devs had some good news and bad news. The good news: they were happy with his work! The bad news: during the week the design had been completely changed and needed to be rewritten.

So the rewrite began, with a new design, and once again, too little time left to do the work. Tests went out the window first, but “basic coding practices” quickly followed. The second version was less reliable and usable than the first. Then the Big Boss sent down an edict: this whole system should get its data from their bug tracker, which had SQL integration options.

Once again, it was all thrown away, and a new version began. Mihail started writing queries for the database, starting by joining the three key tables to produce the data they wanted. Then he read the new version of the design doc, published while he was working, and joined the five tables together they’d need. After combining the six tables the design doc called for, Mihail was starting to think the code he was writing was bad.

The workflow that the design called for offered it’s own challenges. After writing the query which joined eight tables together, with a nest of subqueries and summaries, the query itself weighed in at 2,000kb. And that was just for one report- there were a dozen reports that were part of the project, all similarly messy, and all subject to rapidly changing design documents. The queries were all hard-coded directly in a Python script, and the design was explicit: don’t slow down developers by using prepared statements, just use string concatenation (aka SQL injection) because we can trust our inputs! This Python script would run its reporting queries, and then dump the results into tables in the application’s database. Then a web UI would pick up the data from the tables and show it to the user.

The only thing we can say about the results is that the web UI looked nice. The underlying horror that was the code was hidden.

With the project finally done, it was time to show it off to upper management. Mihail’s supervisor starts demoing their system, and after a minute, the Big Boss pipes up: “Why do we need this?”

“Oh, well, it’s a more flexible-“

“No. Why do we need this?”

“Time tracking is fundamental to our billing-“

“Right, but why do we need this? You know what, never mind. Do whatever you want with this, just make sure that all the data ends up in an Excel spreadsheet at the end of the month. That’s what we send to accounting.”

All in all, Mihail spent six months working on this project. Once complete, it was never used by anyone.