Any point to AES on password with hardcoded key? I'm inheriting a project that stores a used password in a config file, which is generated by the user giving their password in plain text, and the project giving back a key generated through .NET's Rfc2898DeriveBytes with a given salt on the aes encrypted cipher text (which the user then has to put in the config themselves). The password is decrypted and used when the project starts up for that user. 

Since the key and salt are statically compiled into the project as strings, it seem kinda pointless to me, like basically its the same as storing a jibberish password in plain text, with added overhead, right?

Am I missing something here?

EDIT

After asking around about the code, the point is that we're giving this application to a different team to run under a network domain account, so we wanted to prevent them from having the password for the account the program is supposed to run under.
Obviously it would be easy to decrypt the password for any serious attacker, but it might help deter casual attackers. Instead of opening the config file in a text editor and finding the password they would have to decompile and decrypt it, or snoop the memory while it's running. It might also help to stop automated tools that may be searching the filesystem for documents containing things like "password=xxx".