A graphical debugger for LALR(1) parsers (about 6k lines). I wrote the LALR(1) parser generator, a debugger, a state machine visualizer with automatic graph layout, and an XML-fed hyperlink widget for Perl/Tk. I think of myself as having written 100%, despite using Perl/Tk and several other modules -- because I find that if I think of things that way, I'm both happier and more likely to reuse CPAN modules.
Things that enabled me to pull it off:
- Primarily, focusing on having something releasable without being perfect. If I had "finished" any single part of it to my satisfaction, I never would have released anything.
- Heavy use of CPAN modules, of course!
- Don't think too hard about making everything nicely modular initially. It's much easier to write a huge wad of stream-of-consciousness code and then go back and figure out what can be refactored into reusable pieces. (This might be a personal bias, because I suck so badly at up-front design.)
- Come up with a small number of nontrivial and representative test cases early on. I personally don't care whether it's before you start implementing or during, and I tend to leave the exhaustive test cases until afterwards. During the main implementation push, I prefer to work from a small number of tests that I get to know intimately well.
- Try very hard to plow through the things that are more likely to be showstoppers early on, when you're still enthusiastic and flying along.
Biggest mistake: probably allowing myself to flail when I get stuck on things. Instead of stepping back and figuring out a simpler way of approaching the whole area I was having problems with, I would tend to accrete special cases, debugging code, large commented state machines, painstakingly detailed descriptions of what some insanely complicated function should be doing, etc. There's probably a better way to summarize that -- perhaps it would be "my biggest mistake is trying to solve problems by making them more complex instead of simpler"? Something like that.