Another one that started as a Quora answer:
Thank you so much for including the phrase “the right software” (emphasis added)! So many people are interested in simply building software faster, rushing off the cliff of solving the wrong problem!
First and foremost, we have to make sure that what we’ll build is indeed “the right software”. This is all about requirements analysis. Unfortunately, that is far more involved with domain knowledge, psychology, and for major programs, prediction of the future (requiring even more knowledge of the domain, and its current trajectory), rather than anything to do with actually writing software.
This will help us build the right software faster by reducing false starts in the wrong direction. Once we’re going in the right direction, though, we have to make sure we keep going in the right direction. There will invariably be details that crop up later and get misinterpreted, and the stakeholders will often change their minds about various parts or even the whole thing.
Instead we need to use a small-a agile approach. (Not necessarily some defined big-A Agile Methodology.) We need to check in with the client once in a while and ask: “This is what we’ve done. Is this what you wanted? Also, this is what we’re about to do. Is it what you still want?” This could be done weekly, monthly, whatever, depending on the size of the chunk of work to be done, but as often as practical for that work, and as simply as possible so as to minimize its overhead.
Where this affects actual coding is that the code should be as adaptable as practical, where things are likely to change. This means heavy use of separation of responsibilities, dependency injection, swappable wrappers around third-party libraries and services that can be otained from multiple sources that operate differently, and so on. Quite a lot of the standard software engineering advice, especially in the Object-Oriented community, is aimed precisely at this, so I won’t go into further detail.
Now, how to build it faster? Mainly, do not rush! Rushing leads to errors and cut corners, which mean taking the time to fix it or do it over. Take the time to test it, including writing automated tests. Not only will they help ensure that your software is correct now, but also later they will serve as a regression test suite, to give you the confidence to refactor as needed. (You don’t have to write the tests first, just make sure that you do have high test coverage. Ideally, also use techniques such as mutation testing to ensure that the coverage actually means what you think it means.)