Wins and Trade-Offs in Software
Repeat after me:
No such thing as perfect software.
Software is never truly finished. It's always in a state of constant change and evolution. From improving efficiency, security updates, and enhancing user experience, to fixing inevitable bugs, it never stops changing.
This constant change is not without its challenges though.
Picking the "right" software architecture, for example, is like picking the right battles and then managing the trade-offs. It can almost always be improved mainly because business requirements and specs change.
People always bring up examples trying to reason about software development that everybody can relate to. Examples such as, software is like building a car because everybody can understand what a car is. First, building the wheels, then the engine, and chassis, and finally putting it all together.
But software is not at all built like a car because people know exactly how a car should look and how it should work while in software development there's always a big unknown.
When thinking about a software project and developing it, there are always some elements that were never built before and it's always unique to that particular software project; I'm not talking about implementing a login screen for example but the overall project and how all the various elements should work together.
Developing a feature to work in a particular way is not a guarantee that's how users will use it or if they will use it at all. It's like building a car to be driven on the road, but users would like to fly with it.
The most important property of a program is whether it accomplishes the intention of its user -- Charles Antony Richard Hoare
There's a saying among software developers that in the first iteration of developing a feature you learn about the problem, then in the second iteration you implement the solution, and in the third iteration you make it performant.
This is why sometimes you "win" by implementing a particular feature and that feature is well aligned with user requirements, and sometimes that feature implementation turns out to be a "trade-off" between expectation and reality that eventually must be aligned to move forward.