Two terms that I like when building software. Let's define what these two mean for me. This is a bit of a brain dump on some of my thoughts.
(1) Robust Software
Robust software is basically software that -works- as you expect, and when it -cannot- work, it tells you why. Emphasis is placed on the latter, because the importance of recovery is easy to overlook when it comes to a feature specifiction.
When something fails, it shouldn't be silent. Working as a support engineer for a few years has made me value debug logs a whole lot more than before. There are many, many ways a program can fail. Despite the failure being "unexpected", programs should avoid saying just that. That's just asking for support tickets.
Did an "unexpected" network failure occur? Tell the user to check their network. Get specific. Those specific details can greatly help someone knowledgeable. A key with robust systems is that you can easily tell what is wrong in an "unexpected" failure. I like to call rare exceptions as "controlled" when we do handle them gracefully. A controlled failure is when you have encountered a rare scenario, but you have some knowledge where the exception came from. You can guide the user how to fix it. Even better if the system can try to recover automatically.
I have seen a lot of code that skips over exception handling (especially in notorious JavaScript). It's not the end of the world for an expert, but it is going to be nearly impossible for a normal user to get past the issue without help. I guess we could say, essentially, a low rate of failure combined with ease of recovery makes your system robust.
(2) Flexible Software
When developing a software specification, it's very, very easy to end up with a naive design. One of the tips offered by The Pragmatic Programmer (David & Reid) is "Think! About Your Work". It takes time to think. I'd say you are trying to predict the future. You don't -really- know how exactly your users will use your product--feedback is a critical part of development--but you can try your best to predict use cases to make your product flexible.
Already have a spec? Don't follow it blindly. Be mindful. Your manager might actually encourage -not- being mindful, since the additional "thinking" is costing them time and money. It might not be part of the contracted budget to think (loosely termed); however, I do not like that methodology. I'd say being stingy with contracts hurts the company's future. Sure, you need to set boundaries with clients, but don't go sacrificing quality for no good reason. At least communicate potential problems you have identified with flexibility, maybe the client will broaden the contract. At the very least, they will very much appreciate the communication.
Flexibility isn't just baked in the features, either. It's a fundamental principle of good software development, e.g., "Don't depend on concrete classes". I worked on a client project a couple years ago, implementing a microservice. It came up on a call how they wanted to use an SMS service that was not in our original specification at all. As a decent programmer, we expect the system to evolve; we keep flexibility in mind during development. We could tell the client that their service could be supported easily. After all, I had kept the connectors as flexible interfaces, predicting that someone might want to use a different service than we originally supported. Happy client.
Flexibility aligns with many other good development practices, e.g., reusability, extensibility, maintainability, etc. I like the term "flexible" because it's simple, something non-engineers can grasp easily. The more flexible something is, the more likely it can be used for a long time.