The perfectionist in me says: Well structured, elegant code, that works flawlessly to meet all of the user’s feature wishes without bugs. But that’s extreme perfection, and we can rarely reach that point. Not every code file of an app’s code base is going to be robust, but such are the down-to-earth time limits of life 🙂
The better answer is my realistic side: An app that first does what users need it to do, leaving out unnecessary features or ones that take too much time for their value, and depending on the estimated lifetime of the code base, that it’s appropriately structured into services, layers, and classes.
Now over the past 13 years, with the hundreds of small-large features and apps that I’d created, I’ve had about half of them (apps, reports, and db procedures) that I’m very proud of because they meet the above high standards, and others that I’m also proud of despite meeting those elevated expectations, because of useful features I helped add that benefited the end users and/or how stable the system was.
Examples of perfection based apps were ones that were on the smaller scale in size. Dealing with saving permission to a database, reports, or processing a small about of payments, stuff like that.
The ones where I had and continue to have to be more of a realist for are medium to larger apps where the payload and object graph was larger is where things got complex, as there were a lot of moving parts. The team I was on had made the program operate as needed together. Some features didn’t go out exactly as scheduled, but the best part was the most critical features were pushed out first, as they could be, and it helped the users get a starter of using the app and also able to report any remaining issues outside of dev or qa departments. I’ve moved away from my last position of 7 years as a Services and Database developer to be in a new IT environment to stimulate my mind, and solve business problems via software with users, and am pretty excited in this moment for what good things the future brings.