On the merits of spaghetti methodology

Recently, a specialist from a friendly service company came to our company with a presentation of the classic spaghetti programming approach. Below is a retelling of his lecture. The presentation caused a lively interest and discussion (among managers).

During the lecture, we learned that there is a design methodology that works in most simple and medium-complexity projects, and it is recommended to change it only for large and growing ones, starting to rewrite the functions anew at some stage.

The manual was inspired by the results of the presentation, as the advantages of the approach at the stage of introducing new functions into the project were clearly shown:
1) the minimum entry threshold for new developers;
2) excellent integration with Scrum and Agile methodologies;
3) the stability of the project in relation to external refactoring;
4) simple integration of new programming languages ​​and modern technologies into the project;
5) reduced cost of development of the project element;
6) the highest speed of creating presentations, patches and add-ons of a working project.

So far, our team has tried to stick to the more traditional structured, OOP and MVC approaches. But under the influence of the market it is necessary to try out new methods. After all, the time for the development and refactoring of architecture was practically not allocated to us before, and what could be done was repeatedly criticized by managers for the complexity and raising the entry threshold for newbies, as well as for the fact that our frameworks were easily broken by the managers themselves when they were deployed project, but forgot about the rules of the methodology, which we have not been described, because (see above) time was not allocated to it.
')
Then, during that presentation, it became possible to eliminate a number of annoying flaws. Of course, you will have to fire several key developers who will not agree with the new approach, but it will be possible to write simple code, without classes and lambda functions, understandable to the majority of developers with experience of 1 year and recently joined the company.

And indeed, in fact, our managers have a number of beginning projects. Why waste forces on architectural elements that are unnecessary at this stage, and even more so, classes or modules? The approach proposed by the rapporteur showed that, if necessary, in the future, any architecture is easily incorporated into the spaghetti project. If a developer architect cannot do this, he simply does not match his rank. Spaghetti retains the flexibility, and much more than Agile , which the speaker showed, in 2 minutes by introducing the alert () command into a new project for him; and shutdown. There is no need to spend a week on the iteration to change the project - in some cases, a couple of hours is enough.

Let's take a closer look at the basics of spaghetti methodology.

While other high-level approaches are trying to impose a certain structure on the project, spaghetti is initially free from this disadvantage. It does not contradict any new project structure, does not prohibit changing the structure during project development and contain a group of unrelated and even conflicting technicians. The latter manifests itself already in complex projects, but the experience of numerous companies shows that in these cases the spaghetti approach, due to its unique flexibility, prevails over a number of other, more rigid methodologies.

The idea of ​​spaghetti lies in the origins of machine code and the fundamental principle of transferring control of the thread of program execution. We know that there are other approaches in contrast to the Von Neumann architecture, but none dominates the computer market, not to mention software systems.

What gave new half a century away from spaghetti?

It must be admitted that many experiments tried to get rid of it. For example, a structured approach to programming highlights the fact that program management most often needs to be not only transferred, but also taken back. We got rid of GoTo as a destructive operator, but why have we heard again in recent years that jQuery also creates spaghetti code? In a language in which all operations are structured? It turned out that spaghetti can also be written structurally.

Why does a novice programmer almost always test the spaghetti approach, only layering of methodologies shifts his views? Why are there crutches programmers who easily digest such code, written by themselves, can fix any system without source codes, find the source of almost any bug?

An interesting variant is mixed with structured programming: a new function, class or block can be written in any part of the project, using nested calls and data structures, but the project, despite the structural calls, will have the format of spaghetti. The nature of spaghetti lies deep in the nature of things and human activities. Therefore, the approach and its features should be given due attention, especially at the stages of the formation and development of the project.

It is not necessary to do it difficult, which is initially done simply - any advanced start-uper, the same crutch programmer and businessman who knows how to count money and who sees the real state of things when implementing projects, know this. Do not immediately involve specialists in the creation of complex systems, if your system is simple. This is confirmed by numerous facts both of the work of spaghetti systems and of migration from them to more complex ones when they are needed in the future.

There are special code binding techniques to turn a project from a structural one into an unconditional spaghetti project in order to complicate the disentangling of structural loops. After all, if we leave the structural challenges without binding, followers when refactoring can easily distort the idea of ​​architecture and unravel a tangle of spaghetti. This is unacceptable on some projects, therefore binding techniques have been created and are being developed:

1. add mixin functions (even better, methods) called from the block into which this section of code was placed. It makes sense if the rest of the calls come mainly from other blocks;
2. rename similar functions, methods, and make enough differences in the arguments and content to make the reverse recovery task impractical. Novice developers often use a more primitive copy-stream technology instead of this approach, which is easier to refactor, depriving the authors of the project of a strategic advantage;
3. use analogues of existing methods in the project, which is more time consuming, but guarantees better coherence of the project.

Spaghetti methodology is not an invention in programming, as is commonly thought

This approach has long been successfully used in aviation:


(integration with a modular approach is visible),

in urban planning and logistics:



in agriculture:



In system administration:



That is, in rather responsible and important areas of activity. Therefore, criticism of complex spaghetti-software systems that combine both resistance to change and susceptibility to personnel of various skills is not always justified.

Spaghetti methodology in programming has adopted the best of what exists in nature, human activity and complex systems in order to quickly and fully participate in solving national economic problems. State computer centers often create suitable conditions for its implementation, because they combine a number of contributing factors:

1. High level of hierarchical organization for decision making.
2. Flexibility in setting and modifying targets.
3. Extreme financing conditions.
4. Adequate staffing level due to low staff turnover.
5. Long-term planning in conjunction with paragraph 2

Not lagging behind the state and private business. Recall that the first computers and systems were built precisely on this approach, and only the development of technology and computer science found new forms of employment for programmers and managers. Now it is proposed to return to the sources and draw all the best that humanity has gained since the 50s of the 20th century.

Methods of working with spaghetti code

The speaker showed some methods for solving complex problems arising from the flexibility of the methodology.

For example, good results are given by graph representation of interrelations, where it is easier to trace the threads of control to a specialist and is often more effective for presentations than XML and JSON files, even if they are also represented by structures.

With a large number of links help color markers threads. See how simple and clear the idea behind them is:

And how much easier it becomes to understand the initially complex scheme:



It allows you to see the relationship in even weakly related phenomena, as an example.
If a classification of nodes is required - similarly:


Usually at this stage, the speaker said, the managers and the majority of developers already welcome the approach, and only a small part thinks about their experience and tries not to look at the charts.

It has been argued that such schemes are usually not used in software environments, but are more relevant to data and to presentations. But there is no doubt that if the methodology allows you to provide everything, then the rest is only up to the developer and his abilities to be able to use it.

Existing IDEs for any programming language, like multilingual ones, are focused on the use of spaghetti code. For the simple reason that otherwise they could not work with the most complex cases of coding, they also help the developer to search for project names, code sections, highlight keywords and redirect viewing focus from use to definitions of functions, methods and classes. In fact, all the dozens of tricks in the IDE are working with just spaghetti code, and only a few of them work with other methodologies (OOP, TDD, repositories, scram, ....).

Therefore, it is easy for experienced developers to work with spaghetti code, precisely because they know a lot of work techniques, a lot of techniques in various IDEs, and have their own workings like macros in editors or even in support systems and code assembly. Therefore, the question of simplicity and complexity of the representation of the source code in a particular methodology is a completely non-obvious question. If your developers, the lecturer says, avoid working with unstructured code, this may indicate their lack of qualification to master the spaghetti methodology.

Further, the lecture slightly deviated from the main topic, the customer showed the mind maps managers:
,
and then I took them to a closed room, where they spent 2 hours doing drawing and came out very satisfied with the results, right one to one, like tracing paper from last year, when they went to try planning poker , and then introduced Scrum . It seems that this time the question of the implementation of macaroni methodology in our organization is a resolved question.

We list the pros and cons of the spaghetti approach in design.

• + writing any function at any point of the project;
• - adaptation of the new code - with the revision of all uses of it throughout the project (however, as in any project, but if the code is organized, it is easier to read).
• + low entry threshold to start writing spaghetti code;
• - a high threshold for understanding someone else's spaghetti code (but there is a mass of techniques in the IDE);
• + incredible flexibility and “pantheism” of the spaghetti approach;
• - the difficulty in building large systems based on this methodology.

Findings *)

If your organization has not yet acquired a mass of inherited code, or you are constantly starting new projects, you do not have extra money to follow the global trends of huge companies, the ideologues of spaghetti programming will always be ready to help you optimize the process in order to write a function not for 2 days, but for 10 minutes, debug the extension not in a week, but in a few hours. Flexible as spaghetti, agile programmers are looking for opportunities, traditional programmers are looking for a foundation. Flexible programmers write code, traditional ones rewrite it. Flexible - listen to the manager and immediately execute his words, traditional - look for reasons to work on the platform.

* The opinion of the lecturer does not always coincide with the point of view of the editor .