
I stopped worrying about the future and learned to code for the present - fagnerbrack
https://medium.com/capgemini-dynamics-365-team/opportunity-cost-for-developers-a02aa3dc1035
======
titzer
Kudos to the article for focusing on requirements from the outset, as
generally speaking, software development does this all too rarely. I would
paraphrase (and slightly alter) the article's recommendations:

1\. Write the requirements down at the outset.

2\. Rank and prioritize requirements.

3\. Reject requirements that are unreasonable (for now), but keep a record of
them in case that changes.

4\. Try not to make rejected requirements fundamentally impossible in the
future.

