Getting back to code...

I've been getting back to my project, which is a ticketing system written in PHP and PostgreSQL on Linux -- the LAPP platform.

So hard to focus

I've been working on this project for several years now. It's getting a bit old and is a drain on my life and my family. I'd like to get a 1.0 release out, but unfortunately there's just so much more work to be done. The introduction of the customers table and billable hours, two essential pieces that I suddenly realized that I cannot live without, are very hard tasks to pull off. They're hard because there's already a lot of code and with every new piece of code I introduce, I have that much more to test against the existing code.

Customers Table

For quite awhile now, the project has allowed anyone to just type in a customer name and phone number and move on, but that wasn't practical. First, in some customer environments, they don't have phone numbers, they have email addresses or some kind of customer code that uniquely identifies them. Second, you can't have an accounting department bill customers against reports that don't turn up any kind of consistent customer name. Third, it just makes good database sense to create a customers table and integrate it in with the tickets by means of a foreign key.

The problem with this is that I wanted to be customer database agnostic because I was envisioning this system being something that developers would use as a software development kit, and integrate it with their existing customer database systems. Unfortunately after a lot of thought, I realized that this was not going to suit the customers of mine who will not be developers, who want to just purchase a ticketing system and run with it, in addition to being able to bill against its results.

Billable Hours

I've had a hard time judging how to set billable hours for work done on tickets. I want to keep it simple, yet make it uniquely sensible and practical. The only thing I could come up with is that each incident that is typed into the "Work Performed" field should be rounded up to the nearest 15 minutes. Then, when the ticket is resolved, it will return a number of .25 * each work incident as "billable hours". Then, it will offer the tech that works the ticket a chance to change that amount up or down to something reasonable, but no more than .60 * each work incident, with a cap of no more than 12 hours. This sort of prevents mistakes, makes the accountants a little happier, and keeps angry techs from overcharging a client an enormous amount. I'll have these values read from a settings file, so that it's easy to customize. Moreover, if a developer doesn't like how this is implemented, they can simply change it to something they prefer.

The reason I don't like timers on work started and work done, per work incident, inside a ticket, is that they're not very accurate. People get interrupted often in a day. If you give them a Pause button, they still have to click it and it leads to a lot of human error. I see this as the only means possible to give a more accurate account of billable hours.

And what if you have a specific charge (such as $135, cradle-to-grave) for tickets? Then, fine, use the billable hours as a way to handle time scheduling of workers, or judge how long certain kinds of tasks are going to take. Then, just count the number of different problem tickets per customer in a month and bill him by that.

Testing, Moving Forward

Here's how I keep moving forward as a FLOSS (Free, Libre, Open Source Software) Moonlighter who has a day job as well...

1. Vent.
2. Avoid the project for a day. Take a good nap on that day.
3. Come back to it and remember that software does not write itself. Pin that phrase up if you have to.
4. Agree on what's going to make it in version 1.0. Don't bite off more than you can chew in this year.
5. If it's on or before July, then agree that this year is the year you're going to get something out the door. If after July, then agree to get something out the door by next July.
6. Get in the programming mindset. Type fast, think fast. Drink coffee. Listen to Swing Jazz because I've found this to be unobtrusive to programming and speeds your mind up. Eat crackers because they don't get you that fat, give you a small dose of energy, and make you less inclined to get up for a real meal.
7. Start your testing by going to the main page of the web project you're working on. Write down the title of that page in a notepad. Write down all that you see that's broken. Click the first link from top left to right. On each page, repeat the process. Go back up to the top level and go back down again. As you go, if it suddenly dawns on you something important that might not be captured by this process, immediately write that down because it may be important and you may forget about it later.
8. Now take that list of work and type in the word "DELAY" before each item that is just too huge to tackle right now. Move on to everything else, from the first item to the bottom item. By using this technique, you build excitement and momentum in your project, like there's a sense of accomplishment here.
9. Now tackle the delayed items, which take longer.

Augh! So hard to do sometimes.