Once I Built a Timesheet [11/10/2006 23:12:36]
Early one morning, while working for Abel Solutions and stationed at CARE, I got an email from Kevin Abel asking me to fill out a timesheet, which he provided as an excel spreadsheet.
I told him no. There were already a handful of programmers in our company, and I knew that mailing spreadsheets around week after week was going to be a nightmare. Besides, we were a company that built intranets. We needed an intranet solution. So I whipped up a timesheet application in ASP.
It was just a simple blog-like list of entries, with each entry containing an hour count and a link to a particular project. There were some simple reports for the boss. Everyone in the company used that timesheet app, and we used it for several years. It worked great, and I wrote it in maybe four hours.
I don't think I could do that today. Not with my web framework. I still write quick little scripts all the time in the shell for my sysadmin work, but a web app? Well, actually, I wrote the high score module for brickslayer pretty quickly. But I wanted it to be as simple and usable as possible. So I wrote it in PHP.
So now Liz and I have installed a couple apps to help me automate things. Specifically: roundup for tracking bugs and projects, and cerberus for tracking tickets. Both have all kinds of fantastic features. And yet, it's a real struggle trying to adapt them to my way of working. They both seem overly complex, and I feel like I have to master this huge amount of complexity in order to get them to do what I want.
The thing is, I feel the same way about my framework. Hell, I have Liz sending me a spreadsheet with her hours on it because the timesheet app I made back when Mario worked for me fell prey to bit rot, and getting it working again just seems like a massive pain in the butt.
I believe the ideas in my framework are better than the ideas in the old versions of ASP that I used to write that first timesheet. But there's so many of them. And while the ideas may be good, the implementation often isn't. Simple example: you can't edit a zebra template in dreamweaver. You can do that in PHP, or ASP. That's why I like Kid so much: it's embedded in XHTML. (Plus it has named templates - the equivalent of subroutines.)
So, for a huge app like my control panel, it makes sense to use the framework, because the power is worth the headaches. Only it would make MORE sense to use a better framework that kept all the power but let me move fast.
I used to be fast. I was known for it. Linkwatcher was the first blog search engine and monitor because I was fast. I had a prototype up in like one day. I announced it on a mailing list us early bloggers had, and I remember Evan from Pyra (Blogger) saying something along the lines of "Dang. you beat us to it." Well, damn straight! I was fast.
I first tested out the ideas for platonic in an app I did two (?) years ago for Abel Solutions. They needed a perl app written fast, and they knew me, and I delivered. I whipped up a mini template language and a mini ORM and a mini platonic, which let me write the app test-first. When I needed a feature my mini framework didn't have, I coded around it. That's how I moved fast.
I guess the word I'm searching for is micromanagement. I want every line of my code to be perfect. And some of it comes close. I've gone over the strongbox module so many times. I'm proud of that code. But some of the other modules.... Well, they're old and rusty and full of bugs. So when I go to use them, I'm constantly tweaking them. I don't work around flaws and move on. I get all up in that module's business and start telling it how to do it's job.
No, no, no. I should have learned this from the perl app: the important part is the business logic. As long as there's a template system and a routing system and an ORM, I'm good. I don't have to own those things. I'm pretty sure I called the template engine CrappyTemplate. It was crappy. Just a line-oriented one-pass search and replace tool powered by regular expressions. I think it had a for loop and an if statement, but if you wanted one inside the other you had to use numecric suffixes: if1(for2(if3...)))... Didn't matter. It got the HTML out of the way so I could test the business logic. (There were political obstacles to getting third party modules installed on the server, or I'd have used a real template system. We managed to sneak in CGI::Session toward the end.)
The lesson there was to get the framework out of the way and focus on the app. It let us move fast... Fast enough to keep up with the requirements changed every day anyway. :)
Now I know I've been suffering from a massive case of Not Invented Here for several years now. In my defense, the tools that were out there when I started weren't as good as Kid and SQLAlchemy and even Rails. (Zope might have been better but the docs sure weren't.) I gave up the speed of PHP for the power of my framework, but these days there are tools that offer both speed and power, and I should have adopted those tools a long time ago. Because it's good to be fast.
But if I can be fast at the programming level, do I have to put up with bloated, overbuilt tools at the business level? Tools that don't quite do what I want, and don't integrate with the rest of my stuff?
No, I think if I can be fast at the programming level, then I can write simple apps that get the job done and play nice together and solve my problems exactly.
Enough ranting. I'm gonna write some code.