But often the best code you can write now is code you’ll discard in a couple of years time.
Provocative yet brilliant. Furthermore:
But often in the early period of a software system you’re less sure of what it really needs to do, so it’s important to put more focus on flexibility for changing features rather than performance or availability. Later on you need to switch priorities as you get more users, but getting too many users on an unperforment code base is usually the better problem than its inverse.
This is tangential from the original post but this reminds me of most developers’ mindset towards application development: a list of features to be implemented rather than a problem to be solved. Often, we assume that software is defined from the get go. This couldn’t be further from reality.