Skip to main content

How To Enjoy a Week of FogBugz

I have been on an eternal struggle to find the rights tools to keep me organized and on track with my projects. Flying blind is just not something I can do, with such a wandering mind. I especially like time tracking tools, because if I am tracking my time in a task, I am far more likely to focus on it until it is complete. Distractions make a lier out of me. When Joel Spolsky blogged about the Evidence-Based Scheduling in the newest release of his FogBugz product, I finally decided to try the service out for a new project I am starting on over the holiday. It has been about a week and I already have some really good impressions.

As far as bug tracking goes, FogBugz seems to be bare a good deal of similarities with Bugzilla, but is still very familiar to a Trac fan. They've even added a Wiki, although I've not used it. I'm working in solo on my FogBugz trial, right now. (More on that later.) I do wish for dependancy field on cases, instead of just linking to them in the comments. Overall I don't have many wishing for the case tracking itself, and I'm barely using the features available.

The listing is very customizable and I've taken advantage of a few different configurations already, so I can definitely see myself finding more that are useful. There have been some things I haven't found the right fit for. Notably, areas and releases have been a little awkward. Many things cross over different areas of work, so I don't have a clear separation there. I kind of wish for tags, instead. As for releases, there simply are not good uses for those when a project is so internal. I can just make a release for when we decided it is done, but then the field is as useful as not existing at all. I tried to make pseudo-releases for different milestones of functionality, but I am not sure if that is a proper fit.

Time tracking, the very thing that drove me to try FogBugz, is possibly my favorite part. Seeing what you guess and what you actually take is revealing. I seem to guess over, usually, but I wonder if I'll see my task estimates actually getting better as I use this over a period of time. The feedback may train me. I've even found, so far, that the release estimations seem to be pretty well calculated and I've hit the dates its estimated pretty well. I want to write more about my thoughts on estimation and how well you can estimate what you can't design until you've done much of the things you need to estimate in the first place.

I really am loving it, but I know I need to wait out my trial before making any final call. I think it is well worth the cost over the free Trac and others, even for personal use.

Comments

If you plan to use FogBugz for personal projects, I would recommend going to Settings->Your FogBugz On Demand Account and switching to the "Student and Startup Edition". In that mode, you can use our hosted version of FogBugz for free indefinitely so long as you have only one or two users in your install.

Popular posts from this blog

Why I Switched From Git to Microsoft OneDrive

I made the unexpected move with a string of recent projects to drop Git to sync between my different computers in favor of OneDrive, the file sync offering from Microsoft. Its like Dropbox, but "enterprise."

Feeling a little ashamed at what I previously would have scoffed at should I hear of it from another developer, I felt a little write up of the why and the experience could be a good idea. Now, I should emphasize that I'm not dropping Git for all my projects, just specific kinds of projects. I've been making this change in habit for projects that are just for me, not shared with anyone else. It has been especially helpful in projects I work on sporadically. More on why a little later.

So, what drove me away from Git, exactly?

On the smallest projects, like game jam hacks, I just wanted to code. I didn't want to think about revisions and commit messages. I didn't need branching or merges. I didn't even need to rollback to another version, ever. I just …

Respect and Code Reviews

Code Reviews in a development team only function best, or possible at all, when everyone approaches them with respect. That’s something I’ve usually taken for granted because I’ve had the opportunity to work with amazing developers who shine not just in their technical skills but in their interpersonal skills on a team. That isn’t always the case, so I’m going to put into words something that often exists just in assumptions.
You have to respect your code. This is first only because the nature and intent of code reviews are to safeguard the quality of your code, so even having code reviews demonstrates a baseline of respect for that code. But, maybe not everyone on the team has the same level of respect or entered a team with existing review traditions that they aren’t acquainted with.
There can be culture shock when you enter a team that’s really heavy on code reviews, but also if you enter a team or interact with a colleague who doesn’t share that level of respect for the process or…

CARDIAC: The Cardboard Computer

I am just so excited about this.


CARDIAC. The Cardboard Computer. How cool is that? This piece of history is amazing and better than that: it is extremely accessible. This fantastic design was built in 1969 by David Hagelbarger at Bell Labs to explain what computers were to those who would otherwise have no exposure to them. Miraculously, the CARDIAC (CARDboard Interactive Aid to Computation) was able to actually function as a slow and rudimentary computer. 
One of the most fascinating aspects of this gem is that at the time of its publication the scope it was able to demonstrate was actually useful in explaining what a computer was. Could you imagine trying to explain computers today with anything close to the CARDIAC?

It had 100 memory locations and only ten instructions. The memory held signed 3-digit numbers (-999 through 999) and instructions could be encoded such that the first digit was the instruction and the second two digits were the address of memory to operate on. The only re…