What is the reason for the constant reworking of the code?

Question

Project management

There is a customer, there is a developer. The customer wants the developer to make a complex application. The developer implements, implements, and then, when we write "far" modules of the system, which are based on the first modules,
the code of the first modules is either reworked or deleted and rethought, because the logic or interfaces are incorrectly implemented. And so for half a year.
The efficiency is extremely low. The work is going on, the clock is spinning, and the work, in principle, is done professionally, but goes to the removal or alteration due to the fact that something is wrong.
In short: Constant reworking of the project code and pushing back the release. What is the reason?

Answer 1

In fact, refactoring is an essential element of the development process. Nothing without him. In the later stages, unaccounted details are sure to emerge. In addition, the developer himself is developing and striving to improve what was written a few months earlier.
But if, as part of refactoring, a programmer commits more than 20 files at a time, then there is an option that he does not see the whole picture, therefore he saws a "super-flexible architecture". In this case, you can sit down with the developer and make a mindmap of all the elements of the future system and the connections between them. This will be useful for both the developer and the project manager.

Answer 2

There are many reasons:
1. Business always needs urgently. Because of this, the manager/customer shakes hands and says "not up to architecture and most importantly faster", as a result, crutches are sawn, which roll like a pancake lump and at some point you need to rewrite pieces of the structure in order to simply have the technical ability to work further
2. If it was bold in terms of resources and time initially, and such a problem is not the correct architecture,
saving on tests, etc. will do - the fault of both in this case)
4. This is not always bad. First, they quickly launched (tested the hypothesis, received the first money, investments, etc.), thenthey are redoing it according to plan (it’s just that this plan may not be spoken out, hence the bad expectations and the feeling of low efficiency, but it may just be high).
Always, always a mistake of management - somewhere they agreed, somewhere they didn’t stipulate something, somewhere they didn’t take it into account, somewhere they pressed it, somewhere they neglected it, they didn’t clarify their expectations, somewhere they saved money on choosing a developer, and so on. ,
UPD: Urukhayy is not about this project?
Can a project be built with low quality code and be in high demand?

Answer 3

Constant reworking of the project code and release release. What is the reason?

That the project is alive. That's the way it should be.
Constant changes and refinements of requirements during development (if it is long) and project maintenance is normal.
Read about common life cycles: https://habrahabr.ru/company/edison/blog/269789/
Half of the answers under your question - people do not understand what they write at all, due to lack of experience, assuming that you can make a waterfall for a large project.

Answer 4

Repair cannot be FINISHED - it can only be STOP.
https://www.inpearls.ru/

- © Mikhail Zhvanetsky

Answer 5

In the developer's inability to design a flexible application architecture and write extensible code.

Answer 6

The customer wants the developer to make a complex application.

Reason/feature 3 : sometimes it's inevitable: business changes, needs change too.
Sometimes this can be avoided by not pushing the requirements too "far" - obviously, there is no point in implementing something that ALREADY NOW seems to be unsuitable for the requirements, BUT this is not always noticed in time. A lot of people are working on the project, everyone has slightly different ideas about the task, or even worse: not everyone and far from always talk about problems with the system that are already visible "on the horizon", saying that "everything is written in the TOR, but we do according to TK". You can google articles about the cost of errors at different stages of development.
Reason 4: the customer, developers or both do not know how to stop and choose the necessary and sufficient functionality for the first or next release. Lately, I've been convinced that it's a whole science - to stop in time and not expand the list of "super-needed" features, of which a third will be almost unclaimed. This happens especially often when the business is already working somehow (for example, on Excel tables or Access databases), and now it's time for automation, but the release is constantly being postponed, because "I want to do this, and I would do it right away." In other words, sometimes you need to decide on guaranteedrework in the future for a release now. An assessment of the possibility and cost of such "alterations" - i.e. wait and redo it now or release it and redo it later (respectively, with an increase in the cost of "alterations") - and there is that very science. The developer usually sees only the architecture, and earlier understands its shortcomings/limitations, it is difficult for him to decide on the release of something that will not ideally solve the task.

Answer 7

Typical example:
There was a thing that sent a message to the desktop application with a message about the current state of the system. She worked like this for 3 years, everything was ok with her.
New requirements have come that you need to add one more file format when forwarding, plus add a special grouping.
The situation turned out to be:
As a result, due to one new thing, alterations began in three key modules of the system.

Answer 8

Carl Vigers "Development of software requirements"

screenshot of the first page of the first chapter - about you

Answer 9

this is the norm

Answer 10

As far as I can tell from your question, the reason is that you don't have a holistic approach to development. If you don't want to do a lot of redoing, work the "waterfall": hire an adequate architect and design the whole system before coding. And if you don’t want / can’t / can’t design in advance, then follow the agile. At the same time, you will have alterations, but at least the releases will become short.
And you seem to have no methodology, which leads to inefficient spending of funds by your customer.