The really important thing if you decide to go this route though is that each "thing" that goes on part of the box needs to be a complete feature. Typically projects aren't approached in that way - if someone builds out the front-end UI because that's highly user visible but someone doesn't hook up the backend (as an extreme example), the fact that the "front of the box" features are done is irrelevant, they're unusable without the less sexy stuff.
Not to say that it isn't possible to divide a project into independently "complete" features, it's just something you need to be really intentional about.
Absolutely correct. I’m big on infrastructure. Infrastructure is not “shiny,” at all, most times, but it’s the glue that holds the whole shooting match together.
My designs often begin with infrastructure, but I’ve learned to architect flexible structure, as it usually needs to adapt to changing requirements from the frontend, as the project progresses.
In fact, I’m actually doing exactly that, with a backend connector layer, in my current project, right now.
The connector SDK (and backend server) is suffering performance issues, which degrades the user experience to an unacceptable level. Nasty time to encounter this, as the project is quite mature.
The current connector is really not something that can be easily adapted or fixed (I wrote it about six or seven years ago, as a generic SDK, for the backend server, which I also wrote). It needs a rewrite —usually a “death sentence,” this late in the project. I had to think long and hard, before making the decision to do this. If this weren’t a “Front of the Box” feature, it wouldn’t even be a consideration.
Because I always approach these types of projects in a loosely-coupled, “layered” fashion, it makes it easier to “swap out” parts.
Each layer tends to take the shape of a standalone “module,” with a clear, unambiguous, functional domain and API, along with its own testing, documentation, and project lifecycle. They usually take the form of discrete GitHub repos, and SPM packages. That is the case for the current connector, and will be the case for the new one (I already have it set up).
I expect the rewrite to take a few weeks. I’ll probably have the main coding of the SDK done, in a couple of weeks, but adapting the application to the new SDK, and fixing the inevitable swarm of bugs, will take a lot longer.
But it’s quite doable. It will work (I’ve done exactly this kind of thing, many times, before), and the final product will have a greatly-improved “killer feature,” as a result.
So I guess the TL;DR of that mess, is that the architecture, itself, needs to be planned in a way that affords reacting to unexpected stressors.
It depends on what you are doing. Frequently you know you have A, B, C, D use cases in that order of complexity.
A lot of people's instincts will be "Let's try it out with an easy use case like B" and then make the go-forward bases on that.
Then you go to tackle C or D and find out it's a no go.
The better strat can be a spike on D to verify the solution can handle it. This is hack and slash; your validating. After you work on the mature solution.
I've seen so many times people sink time into the mature solution based on A. Then you find out it won't work for D or you finally measure and find out there is no benefit.
a) That hard thing should have been cut out and by definition is not part of the product. Didn't see a bridge with space rocket engines recently, as one could say.
b) Most times nobody knows what is actually crucial to the user -- including the user and management. Books and theses have been written on the topic. Companies experiment until something sticks. There is always the chance a feature is unnecessary.
Really bitter pill to swallow.
This philosophy is not easy for engineers (like me) to stomach.