Most of the responses focus on how you meet the current requirements. However, the most important thing to know is not actually about current requirements, but future ones.
Sure you can assume that all the requirements will change, but then you’ll need to make a system so flexible it becomes a nightmare to do anything (just look at JIRA or other software like it, with 100 configuration options for every piece). These systems require vast resources to maintain because there is so much code to make it flexible.
You can also assume the requirements won’t change at all, tightly following the spec and optimizing all the edge cases so you have a pristine black box no one can touch.
Finding the happy medium involves knowing which assumptions are likely to change, and which aren’t. Usually, languages won’t change often, so you can rely on most of those features. Certain well-maintained libraries and APIs won’t change much, so those can usually be baked-in too. The business logic around things like pricing, users, analytics, data visualization, and data processing are likely to have changes. My favorite one for web apps with databases is search. The filters very often change and grow, so getting a highly flexible search working is usually a big win for not too much effort.
Note, I’ve never said always. If you can get knowledge about the business needs you’re supporting, you’ll have a much better idea of which things need flexibility, and which things don’t. The longer the roadmap on a project, the more wins you can get when architecting systems too, as you can set yourself up for easier implementation of future features.
Sure you can assume that all the requirements will change, but then you’ll need to make a system so flexible it becomes a nightmare to do anything (just look at JIRA or other software like it, with 100 configuration options for every piece). These systems require vast resources to maintain because there is so much code to make it flexible.
You can also assume the requirements won’t change at all, tightly following the spec and optimizing all the edge cases so you have a pristine black box no one can touch.
Finding the happy medium involves knowing which assumptions are likely to change, and which aren’t. Usually, languages won’t change often, so you can rely on most of those features. Certain well-maintained libraries and APIs won’t change much, so those can usually be baked-in too. The business logic around things like pricing, users, analytics, data visualization, and data processing are likely to have changes. My favorite one for web apps with databases is search. The filters very often change and grow, so getting a highly flexible search working is usually a big win for not too much effort.
Note, I’ve never said always. If you can get knowledge about the business needs you’re supporting, you’ll have a much better idea of which things need flexibility, and which things don’t. The longer the roadmap on a project, the more wins you can get when architecting systems too, as you can set yourself up for easier implementation of future features.