Other commenters have already covered some important points - I'm talking from the position of someone who worked for a while in a development team specifically tasked with maintenance of shipped code. Pretty much all of your questions came up time and time again.
There are many things that could be going on. You pointed one out - the original developer may have left the company. Another possibility is that, while the original developer is still in the company, he/she has long since moved on to other things, and no longer has that stuff in working memory (especially if the code has changed quite a bit since they were working on it).
What we had to deal with, for instance, is that the product team had very aggressive schedules for delivering next versions of the product. If they also had to work on bugs in the existing versions, at least so the reasoning went, they wouldn't have been able to meet their schedules. I guess this point could be argued, but the reality of the corporate software world is that getting stuff out the door trumps everything else, including observing all the best practices of software engineering at all times. "Tradeoffs" is the vague term under which fall all the unpleasant compromises us developers sooner or later have to do in those environments.
On the other hand, however, fixing non-trivial bugs requires you to really learn a lot about the codebase. It is painful, sometimes demoralizing, and oftentimes overwhelming. But how exactly do you think you're going to become a subject-matter expert on a software project? You can spend days reading the code for your edification, but that kind of code perusal doesn't really stick as well as having had to "battle" with the code in order to fix a problem. Researches continually trump the motto that we learn by doing. Sadly, unless you're in a startup or a new team, this means that you're usually joining a software project which has been around for several releases, and has real customers with real complains that need to be addressed. This implies that you will be fixing bugs first before you're given functionality to add/redesign.
What's really important is to communicate regularly with your manager and express what you want to get out of the job, and see if the business can actually accommodate for your goals at the moment. Hopefully, the answer will be yes. Stick around for a while and gather all the experience you can from your current team. If the answer turns out to be no, and you're a good developer, you will have many options. But do not discount the experience you gain by fixing bugs - I'm now into my third software job and I have to write tons of code. Fortunately, a lot of it works from the start because I've spent so much time identifying, fixing, and trying to prevent bugs.