Is it possible to write a program without any documentation and terms of reference?

Question

Documentation

I spent the whole of August writing the program the way I like it. Before that, there was experience in other areas (sad), there is a suspicion that documentation is needed that matches the size and complexity of the written software. There are articles on Habré, on Wikipedia, designed for design by a team of specialists (loafers from development?), For me they are useless. I have 11000 lines of code now. I used to expect to take a UML editor and design everything you need, now I have doubts. Questions:
1. Do you need documentation right away in UML, or do you need page-level requirements first in Word?
2. If I do not write the requirements at all now, what does it threaten?
3. But I'll take it and write everything as I see it. And six months later, it turns out that it was necessary in a different way, but it was written inefficiently, and this helped the code at the level of statistical error. Is that a good reason to keep writing without demands?

Answer 1

You ask ... 90 percent do this. Another thing is whether they do it right? Documentation is often confused with design. They are different things and have different purposes.
It is necessary to design, it significantly reduces the cost of development. In this case, you can use UML or banal flowcharts, it does not matter. Sometimes it can fit in your head, but more often it's better to write it down somewhere. And here we smoothly come to the documentation.
The advantages of documentation are that the design solution can be prepared now, and the implementation can be postponed until later (and nothing important will be forgotten along the way), or you can discuss the solution with someone, identify risks, transfer it to someone else for implementation.
The disadvantages of documentation are that it quickly becomes outdated and is quite expensive and time consuming to maintain.
Thus, the key issue is the purpose of the documentation. From this there will be answers on the indicated points.
1. Depends on the complexity/volume of the task. If everything fits in the head, then what is the documentation for? Any, UML or text, it doesn't matter. If something needs to be thought through, then you can write it down on a board / paper, take a picture, then throw it away.
2. Without requirements, we do not know what should have happened. For the initial stage of the product, this is quite acceptable. The main risk is in the regression of functionality. We look at the code and do not understand why it is needed here and how it should work, we change somehow and as a result we break the previously implemented functionality. Such risks are not necessarily solved by documenting the requirements in the form of a technical specification; automated testing can also be managed.
3. A good reason not to do something is to have a clear understanding of how the associated risks are minimized. Down with dogma. If in the medium term we clearly understand that capturing/documenting requirements will not bring any benefit, then why waste time/resources on this?

Answer 2

Probably, first you need to ask yourself the main question: "Why do I need documentation"?
"There is a suspicion" is not a reason. Documentation is created in order to approach the main goal - making money (by reducing indirect costs and / or increasing indirect profits). Costs and profits mean not only money directly, but also time (which, as you know, is also money), nerves, etc.
If you do not have such thoughts at the moment - you do not need documentation.
If yes, make a list of current problems.