Doing the expedient thing
“Do the expedient thing first” is good advice that developers routinely misread as a license to write spaghetti — and in doing so they violate the very premise that justifies the shortcut.
The minimal viable product mantra advises to do the expedient thing first, since you will get things wrong the first time around.
In my experience, developers often draw the wrong conclusions from this (very wise) statement.
They sometimes use it as justification for writing spaghetti up front, piling up reams of technical debt and hacks. And they do it because “it’s faster and we will end up changing it anyways later”.
These people miss an important nuance to the statement, and end up violating the very premise that justifies their up front spaghetti shortcuts.
Here’s my take at explaining this nuance.
When doing green field product development, you should always write code with the knowledge that you will have to change it significantly later. Future ‘you’ will better understand the problem space, and the results of your usability tests will undoubtedly cause your best laid plans to change course. And because of this, it is almost always the right decision to spend 10% more time architecting code now, if it makes it 50% easier to change it a week from now. In other words, it is hard to change spaghetti, and since you will undoubtedly be wrong about whatever you are doing the first time around, you are better off building things slightly intelligently in the beginning. If you do this, it will be orders of magnitude easier to massage it into what it needs to be later.
It is of course a balancing act. You must stay clear of the temptations to overarchitect up front. You must be willing to take on some technical debt, documenting it with a TODO, and moving on. The calculus is subtle, but I can’t stress enough how important it is to overall continued velocity to get this right. I use a similar calculus when deciding to take on a refactor during the early stages of developing a new product.
It makes me smile to see the code that my current teammates are writing. They get this balancing act, and it is really rewarding to be able to maintain such a high velocity as we iterate.