How far do you try to predict the future when designing an application?

Question

How far can we or should we try to predict the future when designing an application? Be it architecturally or in design.

What makes a rugged change-face design without being overly planned?

It is a special case of YAGNI, which in its most radical form (and I believe that original) translates into:

"Always implement things when really need them, not when you just foresee who needs them."

On the other hand, Alistair Cockburn says:

Apparently we cannot discuss the quality of a "design" until we have voted in a future! Credo.

We can evaluate a solution in relation to your space and performance goals (note that to do this, we need to have a space and performance goal! ). We can talk about how "nice" a design looks, how "natural". But we can’t talk about how robust he is without choosing a future to support. Different futures give rise to different optimized designs (as well as different goals give rise to different space and time commitments).

Design problem of a coffee machine, part 2 (part 1 here, is an object-oriented design exercise).

Answer 1

The most complicated part of all I think is really this. Regardless of the architecture and stack you choose, will always fall into this dilemma.

Humbly I will try to answer this in my project manager perspective which puts me daily ahead of pricing and application design.

I would first ask myself the following before starting:

This is a circumscribed process, that is, do we have the current view of the process from start to finish? I can put this into a project (Gantt Chart) and budget it in an organized way?

If yes, in this case it is enough to understand the processes involved, and develop in chronological order in which customers are involved to follow the development.

In this case, few conversations with customers solve. Usually maximum 3 conversations.

We usually break into "must haves", "nice to haves" and "good to haves". After we finish the "must haves" if there is time then we go to the others (say in passing what usually never happens).

In this situation it is known in advance (roughly) the "how much it costs" and "when it is ready".

If it is not something that already works today and we are talking about some "rupture", that is, a new product or service, in which there is no?

In this case the management and development model should be oriented to Sprints. We have a vague idea of how much it will cost and no idea when it gets ready.

In this situation we have a universe in which it may NEVER end because there will always be continuous improvement.

In this case I would say that the "pocket" of the customer or the owner of the thing will tell how far this continuous improvement will follow.

Will it be an MVP? It will be an app of millions invested?

How long the development game will last will be directly linked to the amount or time of who wants to invest in the thing.

Concluding

As mentioned: "different goals give rise to different commitments of space and time".

That sums it up. There are situations where the design is clear and determined. The user needs an NFE emission system integrated with SAP. You don’t need a very bold design to suit you. If it’s web, a bootstrap, coreUI with a simple backend can solve. You’re not going to make a microservice backend app or use a reputable designer to make the form. There’s not much beyond what was once seen.

The client wants an application to estimate the dollar rate in the next 20 days analyzing news on the web and certain sources. This may tend to infinity in development.

Everything goes from the scene and I would say by experience, by the size of the investment available.