We all know the old adage … “Quality, Features, Time: pick two”. It’s a useful reminder that trying to squeeze too many features into too little time will inevitably impact quality. It’s also a useful reminder that focussing only on quality will lead to a reduction of the rate of feature development. And it even works to remind us that if we keep increasing the number of features, we’ll never ship anything!
The mitigations for each scenario? Work out the right number of features for the time you have available. Sprints, prioritisation and MVP help a lot here. Work out a realistic schedule for shipping something, (hint: make it as soon as MVP makes possible), and focus on the right level of quality for the deliverable you need. Heavy engineering is needed if the system you are building is planned to be a web scale app, while a faster, more lightweight approach might be appropriate for an internal tool that will only ever experience light use.
As always, delivering a successful software project is a balance of multiple factors, and the smartest thing we can do is measure and assess the impact of what we do versus what we’re planning to deliver.