When is the software development process completed?

Question

Web development

I hope experienced developers will prompt the answer to the question:
At what point should the software development process be stopped in order to be satisfied with the result, and not think “I could have done better here, and there too ...”?

Answer 1

There is only one answer - when support ends. The support period is set at the design or delivery stage of the project. It can be extended, but not vice versa.

Answer 2

When you decide to close the project, then you can consider the development process completed. In other cases, improvements are possible and necessary.

Answer 3

There are two simultaneous options - never and tomorrow. The project needs to be divided into iterations a week - two at the end of each it must have a working version. Well, the iterations themselves can be planned indefinitely, because a good developer is almost always dissatisfied with the result and wants more, better, stronger.

Answer 4

When there was no one left who could or wanted to do something with the code.

Answer 5

When the project is handed over to the customer.

Answer 6

When no one else is willing to invest money/time in this product, because it either fully performs its functions, or has reached a dead end.
As for when to “stop” - if you are making your own product, then it should be released to the market when users can use it without swearing (yes, you need to test it). And then - sensitively respond to the buglist.

Answer 7

Determine the requirements that the project must meet. When they are achieved, the project can be considered completed.
New ideas (except for fixing bugs and serious flaws) write down for future versions. If you try to do everything in the current version, you run the risk of never releasing it. It is especially dangerous if it is necessary to hand over to the customer.

Answer 8

Software from the user's point of view is evaluated as follows: "with the help of software, you can perform such and such a task, yes or no."
This “may” has two main aspects.
1. Completeness of functionality
2. Acceptable level of errors
Admissible. The task is set - a program for creating texts for their subsequent printing.
Suppose the programmers got carried away and inserted pictures, nested tables, but printing does not work yet. It is IMPOSSIBLE to give the program to users because of point 1.
But if one of the tasks was just typing, then you can give it away - the user will save it to a file.
Modern software solves many problems, but the approach is the same.
Tracking your pace also helps. If the pace has slowed down, then there may not be enough feedback from users to make decisions.

Answer 9

Never. It's like renovation. If about the "theory".
If about "practice", then exactly at the moment when the TK is implemented and all known bugs are fixed.

Answer 10

As soon as he bothers the one who sponsors him.
If this is a custom project, then the customer rules it.
If it is your own, then until you get bored.
If it is a group project, then there is a group or at least one who cares.

Answer 11

"Never". During the first iterations, a working prototype is delivered as soon as possible. By 2/3 of the project budget, the prototype usually already does everything that the customer needs. At this moment, it is best to discard some of the features, devoting time to tests and fine-tuning, enthusiastically involving the customer in this, so that he would not have the thought “he is being thrown”. Under the remaining 1/10 of the budget, they take support at the end (I have never seen a customer want to withdraw the remaining money from the budget). All discarded features are detailed and formalized in v2.0. If your support really doesn’t screw up, then the customer will be happy and in half a year / year will create a new budget, everything repeats. At the same time, you never go beyond the initial budget.
Bottom line: as long as there are ideas, never.
From experience, in order to make the customer happy, one should not be afraid to discard low-priority features. And the vision of priority appears after the first releases / prototypes, and not (as most mistakenly think) at the design stage. Abandoned and new features keep the project in development constantly, albeit with pauses.