Debconf is the only peice of software I've written that is the first software to implement a spec. It could be the fault of debconf's spec, which I didn't write, but doing this seems to be a fairly sucky process, basically you're taking the result of an abstract committee process and trying to turn it into something useful, and you get to find all the bits that were not thought through. This is a unique problem to first implementations; later implementations can just ignore the spec.
Of course debconf is also one of the more important peices of software I've written, and it also laid a foundation that was used by a lot of other work I did later, including d-i, so the pain was worth it.
Come to think of it, in d-i I took the approach of writing a spec and mostly letting other people work out all the tricky bits it didn't anticipate, but that's another story..
As to the code, it was my second foray into OO perl, after perlmoo, and it kinda shows. The shell code parts used to be the kind of shell a brain scarred by working on shoop will produce too, though they've since been sanified.
It seems like in the end it's going to be harder to transition everything over to the second implementation of the spec, cdebconf, than it was to write debconf in the first place. Still, I want to do it, since we have to have cdebconf for d-i and there's no point in mostly the same people maintaining two parallell implementations. Although some parts of cdebconf don't match the power of debconf, I doubt many people will notice.