What would you do if you were in a situation where the project you are working on is obviously built poorly and will have failures in the future and be a nightmare to maintain...but it is considered a "success" by management because the clients are happy?
Should I just not care? Is it ok that the clients don't even realize they could have a better application than this?
At what point do I stop caring about building it right and just go with the flow?
If the clients are happy, you're doing something right. Lots of people enjoy hot dogs without knowing how they are made...
If the app is a good solution to the problem but you're worried that the foundation is faulty, figure out how to improve things incrementally and pitch a plan to implement those improvements as you update the product. Incremental is key: if you're itching to rewrite whole parts of it, your manager is going to rightly say that's unreasonable. The perfect can be enemy of the good. Look up jwz's story of how Netscape let IE take the lead because they "had to" rewrite Navigator.
If the app's UI is itself a mess, the clients may still be happy because they are comparing it to "the hard way" and even a buggy program can be miles better than that. You are comparing it to an ideal that you can imagine because of your background and skills. Again, consider how you can improve things in incremental ways, and pitch that as part of the plan.
Don't stop caring: you want your work to be the best that it can be. But also remember it's the customer that pays your bills, and you're writing software for them, not you.
It's not a nightmare for them. It will be a nightmare for you and they seem to think you know what you're doing, so it will get fixed. Would you rather people who don't undertand programming think your app is worse than it actually is? This is not the exception. Enjoy it while you can. You better hope the client outgrows this app. They may go so far in another direction as a business that this is absolutely useless. You could be rewriting it for a whole different set of reasons than you think.
I don't think you should ever stop caring, even if it seems like the upper management has stopped. I think the important thing to take out of this experience is to remember and document all of the things that you think went wrong. Avoiding these mistakes in the future will eventually be recognized, if not this current group of manager, maybe the next group of managers you work for.
I'd start presenting ideas for the next steps to development that include re-factoring to improve the quality of the code. Stay away from going too deep into technical detail, but do point out how the fixes you suggest will mean continued customer satisfaction. Be prepared to mix cleanup with new features, since management will always be looking for something new to sell.
In general, clients won't care about maintenance until something goes wrong. Ideally, your company would care about it's reputation, and want to protect it by maintaining the code.
However - if this product is viewed as very short term, there may not actually be a value add to doing it right. In that case - look for the cheap fixes - the things with little effort that have a big value for developer sanity.
You don't. You use the success to secure funding/permission/buy-in to start refactoring towards technically correct and easy to maintain. Or you use the success to get promoted out of the "I get to maintain the old codebase" department.
Perhaps your priority/viewpoint is wrong.
The most important thing about any software project is that it satisfies the users requirements.
This is a gazillion times more important that being "correct" according to this months C/S design fashions.
Yes you should use correct design patterns, use the technology correctly etc.etc. but only in as far as it makes it easier to implement the users requirements in a robust and maintainable manner.
A truly badly written system which actually fulfills a business need is always better than a wonderfully written beautifully documented piece of code that nobody wants or has any reason to use.
Try to communicate with the current users and ask them which aspects THEY think need improvement. Then you could improve some aspects that you think need improvement and improve also the aspects that the users proposed. You can justify your improvements as "needed in order to implement user proposed improvements"
For example: if users think the search-function is slow. You can improve that by creating a better Data Layer which obviously serves more than just the search, but you can then justify the time spent.
