[On today’s episode of Developer Tea, I talk about Feature Runways.](http://spec.fm/podcasts/developer-tea/18126)
Where will your application change?
Where is it most likely to go? What will most likely be needed?
Let’s say you’re building a publishing platform.
Will you need to have one post, or many posts? Almost certainly many.
Will you need to have one editor, or many editors? Maybe many.
Will you need to have tags, categories, etc? Maybe.
Will you need to have an API for a native application to consume? Probably not immediately, but maybe in the very long term.
Will you end up printing your publication regularly? Almost certainly not.
Each of these kinds of questions (albeit contrived) have different levels of likelihood for future development. When you see “probably” areas, that’s a runway.
If you build the early versions of your software in a way that blocks those runways, you will have a much more difficult time reversing those mistakes and building future features.
Build your software both as a foundation for change and as a solution for existing problems.
Identify areas of likely change in your application. Begin to plan for the future: what will this look like, most likely, in 3 to 6 months? Is what I am building now making that change a difficult move?
This impacts decisions big and small.
“Should we create different user roles?”
“Do we need to build translation in from the start?”
“Does this provider/platform solve problems that we have now without causing integration difficulty in the future?”
“What tradeoffs does rolling our own e-commerce system have with buying into a larger e-commerce platform earlier?”
“Do the needs of the company require that we consider a particular platform or language? Are we working with another company now, or do we plan to be acquired by a company, that prefers a particular framework or conformance to any special standards?”
Determine how you can use flexibility as a sort of insurance policy against the complications of change. What options require less, the same, or minimally more effort than the proposed option, but ALSO provide more flexibility in key areas? For sustainable software and a better night’s sleep, build a system that is primed and ready for the most likely change scenarios.