project A makes baby jesus cry

And so... for some reason I'd gotten it into my head to volunteer for Project A at work. Project A is a rules engine for processing ... things... Myself and another fellow newbie on the project (Hi Jeff!) are slowly coming up to speed on the crazy.

How crazy? Let me count the ways...

• Release every month!
• Without a project manager, development manager, or release manager. Who needs 'em? Crybabies.
  
• We can't control the # or scope of change requests coming in each month. State regulations drive all the changes to the system. Some nebulous decision process allows us to occasionally drop some changes from the queue... but we don't know which until the deadline has been blown.
  
• Crumbling 12+ year old code base. Not given love or documentation over the years. Occasionally tossed a bucket of fish heads. You can tell which dark corners survived from the halcyon days -- they use the hacked-in exception handling in what appears to be the correct way. While I appreciate the cleverness of adding exception handling to C (preprocessing macros around some setjump/longjump magic), I'd appreciate it more if anyone had bothered to write a brief document describing said 'right' way. An example in the .h file? Pshaw! That's for suckers! In the 3 weeks I've spent diving through the code to correct memory leaks, there's at least 4-5 different exception handling idioms. Many possibly broken sections of code, swallowing exceptions with no comment to explain whether the author did accidentally or on purpose. If there aren't comments, it's usually right... for certain values of right. If there are comments, the author clearly thinks exceptions either work like Java's or has no clue.
• Functions are named as ambiguously as possible with regard to whether it returns a reference to a list that shouldn't be modified, or a copy of the list that's safe to modify and needs to be cleaned up by the caller.
  
• It doesn't matter that developers create the builds pushed to customers, right?
  
• Oh, and developers have been doing the source control labeling too.
• Oh, and they're doing both of those tasks half-assed
  
• The developers have been too lazy or too scared of the HP-UX makefile to allow it to work without manually copying all source files from their CVS checkout directory to the application directory.
  
• You know what'd be a great idea? Basing the fancy new .Net-based Product B's rules engine on Project A. Wait... let's add a Java JNI wrapper around its re-packaged Project A. Awww, yeah... now that's good and f*^@#$ed up.
  
• Cherry on top: some genius decides to branch to support Project B. "Branches are neat! Wait... branches are hard... oh well, we'll just branch this one directory that has the DAO stuff, that code definitely has to be different between Project A and B. That's what branching is for, right?" The branched directory also contains nearly identical files that will be slowly, and not-so-slowly , diverging to meet each project's mostly identical monthly release requirements. What? Labels on the branch/trunk to indicate merged code? Nah, that'd be too helpful. I should consider myself lucky that the branch has only existed for a year.
• Oh yeah, we're releasing Project B mid-Summer. Sweet!

Somehow, I'm the calming influence on Jeff. Probably up to the point where he reads this rant. C'mon, we're in it together! You know, like Musketeers! But less flouncy.

I'm pretty sure I'm living in a sitcom written by The Daily WTF. The alternative is unthinkable.

This is Mark's cue to waltz through with a comment where he doesn't say a thing. Which I appreciate.