How often do we start a project without asking ourselves the right questions? The simplest question that should be set before you with childlike spontaneity is “why”? It sounds crazy, is not it? Recently, I was approached by a student who has yet to study under my guidance a course on “Web programming” with the question of replacing laboratory work with the result of a project that he is going to perform.

We must probably begin by saying that I was greatly delighted by the student’s initiative. In fact, the previous thread disappointed me with the exception of some stars. Apathy, lack of initiative, outright illiteracy and lack of basic skills to predict troubles - these are the main qualities that they revealed to me. At the same time, the initiative on the part of the student caused some confusion.
I decided to deal with motivation and, as it turned out, for good reason.
')
Making a social network with some additional features for a specific group is an idea. The idea, but the person decided to conquer the mountains of difficulties without at all representing the volumes or the essence of the work. Although it should be noted that you have experience in PHP and some knowledge of MySQL. You can say the effect of the second system in action
1 . He already knows something, knows something already, already has some experience and believes that he can do everything. I liked the perseverance with which the student defended his idea. There was a feeling that I was seeing a tank on board with the phrase:
"Do not look back, look only forward, at what you want to do, and you will surely accomplish your plans."
Obsession and lack of experience of failed projects can significantly affect the result even in the initial stages of product development. I do not want to say that the principle “let's code the project quickly” does not work, although in most cases it does not work. Even when the disciplines on the development of IP were at the stage of inception, it was established that the life cycle contains not only “wow, we code”, but also “oops, but how to support it”. Considering that the implementation and support are not the most interesting stages in the development, and that it is in them that the fundamental errors inherent in the design are revealed. That design should be given much attention.
Designing IP based on technologies that you do not yet possess will, in most cases, result in large errors caused by an incomplete understanding of both the methods of using the technologies themselves and the limitations that the technology imposes on developers. Bug fixes are always mean, long, and this completely demotivates the development team.
Actually, another fundamental problem of student air castles is related to teamwork. Ignorance of teamwork support tools (for example, SVN) will significantly impair performance. The lack of experience of the teamwork itself negates most of the efforts of this team. Unformalized relations (without a doubt, the youth team) fertile ground for conflict.

But, if you go back to the original question and put it again, relying on the above, it will not sound so crazy. Why waste time and effort in creating a project that was initially doomed to failure? Maybe you should choose an opponent more or less equal to yourself, that is, as in boxing in some virtual weight category.
This does not mean at all that I refused a student, I already had to try myself that:
“He who persists in his madness will one day be a wise man.”
____________
1 Brooks F. Mythical Man-Month or How software systems are created / Symbol-Plus, 2006 - 304 p.