Imperfection
Perfectionism is a vice I find myself facing from time to time, and it shows its ugliest head when I'm doing software development.
I consider myself lucky that I don't face perfectionism when I'm hacking a quick and dirty Perl script together (else, I'd be a very dysfunctional admin). As many admins, I have a large ad-hoc collection of Perl scripts doing various jobs for me (such as tweaking domain settings en masse on Joker), and though I tend to start at the very least with use strict;, my scripts still end up being an undocumented mess with dangling code and an arbitrary mixture of spaces and tabs (from when I use Konsole's copy-paste to go from vim on one terminal to another). These scripts require a little love to modify and maintain, but they do their short-term jobs very well.
When it comes to "real" software development, however, I hold myself to a very high standard, and hence it always makes me uncomfortable when I'm relying on someone else's code that might be good but lacking. I'm encountering a nice patch of that now.
C++ is a language I'm perfectly comfortable with, but I always prefer C when all other things are equal. The toolkit Qt's excellence is more than enough to swing the pendulum when I find myself developing a GUI application. I was planning on using Qt for a piece of commercial software I'm being paid to develop, but it looks like the budget is going to run shy of what it would cost to acquire the requisite commercial licensing.
In short, I'm having to take another route. Considering that my immediate need for a toolkit is based on the need for a cross-platform API (and the opportunity to avoid Microsoft's hatchet job on the C and POSIX standards), the alternative that most quickly rises into the picture is the GNOME libraries. GNOME doesn't offer a unified toolkit; rather, it looks like I'll have to work with GTK, GLib, Cairo, GNet and possibly others.
That's a pretty substantial amount of unfamiliar territory for a project on as tight a timeline as this one. The irritation of having so many libraries is that while the individual libraries seem to have reasonable API documentation, I have yet to find a good cohesive document that shows just how it all fits together. While the documentation available for these libraries (and for GNOME) is good, I find myself missing the comprehensive documentation offered by Qt.
I'm also having to gamble a bit that I don't step onto a portability landmine in my development. These libraries are supposed to be portable, but there are areas (such as GTK/Cairo integration) where I'm coding with my fingers crossed, hoping I won't encounter any oddball issues trying to build or run the result on Windows.
I'm also quietly weeping that while Cairo is good, it doesn't appear to hold even the slightest candle to Arthur, Qt's paint system. I was really hoping to have a reasonably easy time adding serious graphics sophistication to the visual presentation of my application.
But what really gets me during the development process is when I run into design decisions in the underlying libraries that make me want to choke the original developer. In GLib, it appears that memory allocation failures are handled by terminating the process rather than passing back a NULL pointer. This may make some people's lives easier, but it drives me bonkers. To me, writing code that can survive memory allocation failures is almost always worth doing. When you adopt a library that decides differently, you're pretty much stuck with their decision.
I'm also a bit unhappy with what I'm seeing in the g_list doubly-linked list API reference. If you want to delete an element, the "normal" functions to do so appear by their description to be O(n). They do offer a function which removes an element via its node pointer, but the only way it appears you can get a node pointer when populating the list is if you allocate the nodes yourself and forego using the convenience functions they offer in favor of g_list_concat.
There are a couple of considerations here that I have to remind myself of. One is that these little things don't matter too much in the grand scheme of things; GLib is good, and it is going to save me some time. GLib is also free, and when I'm not an active contributor to the library, it's best to be kind when throwing stones. But encountering these sorts of small gotchas is one of the things that keeps me smoking and leads to my desire to reinvent the wheel from time to time, just to make the spokes shine a little brighter.
You know... perfectionism isn't always a bad thing, it's just quite incompatible with deadlines.