The usual assumption made when designing a password hashing scheme is that, if an attacker can read your database, they probably can read your code and config files too.
Of course, this may not always be the case: for example, an SQL injection attack might compromise your database without giving the attacker filesystem access. But it does hold in many other cases, and in general, it's never a good idea to assume that an attacker will be less capable than they might be.
So, adding a secret per-application component (sometimes called "pepper") to the salt may improve security in some situations. But you shouldn't assume that it will, which means that you should design your hashing scheme to be as secure as possible even if the attacker knows the pepper. Once you've done that, whether or not you still want to bother with the pepper is up to you.
One thing using pepper can help you with, which is difficult to achieve by other means, is protecting your users from their poor password choices. If a user chooses a very common or easily guessable password, like "abc123" or "letmein" or their own username backwards, and if an attacker manages to access the password database and mount an offline attack on it, no practical amount of salting or key stretching is going to keep the attacker from guessing the password. However, if your password hashes contain a secret key which the attacker hasn't managed to obtain, the database is useless for them and they're reduces to on-line attacks against your application (and thus subject to rate-limiting, which you've hopefully implemented).