There are actually a couple of different problems relating to software development on multiple cores.
The complexity issue is the one that software development is having difficulty with right at the moment: running multiple threads of execution (which is really what you are doing with multiple cores) adds a whole host of issues that you don't have to deal with in normal serial (single-threaded) applications. Priority inversions (where a high priority thread is blocking a low priority thread, but must wait on something from the low priority thread before it can continue), contention (where two threads both need access to the same resource), and thread race (where two threads access the same data, and one thread changes the data without the other thread knowing) are just some of the more common conditions, and having multiple cores compounds these problems even more.
Once these issues are resolved, you still have to deal with the issue of practicality: just what do you do with these extra threads. After all, your typical word processor spends the vast majority of its time waiting on input from the keyboard. What should it do, use multiple threads so it can wait on the keyboard multiple times?
Many applications simply aren't amenable to threading because they are inherently serial in the nature of what they do.
This doesn't mean, however, that multiple cores are not useful. It just means that the majority of their value is actually going to come at the OS level: being able to run multiple applications simultaneously without one application slowing down another one noticably. Most everyone has some kind of antivirus scanner running, and that scanner typically looks at files that are being accessed, web pages that are being opened, and e-mails that are being downloaded. Each of those applications could run on an independent core, and the AV software could be using multiple threads on multiple cores itself for the scanning. This will result in a more positive user experience.