Philosophy of the Art of Programming
Every twenty years, people reinvent the agile agile approaches. Why is that? Let us try to understand the root causes of this, through philosophical arguments about abstractions. 3r360.
3r360.
What is programming? This is an attempt to build a set of abstractions, turning many small details into a single object, and so on, according to the principle of the nested doll, to put everything into one big abstraction with properties and behavior. This is called a system, subsystem, etc. 3r360.
3r311. 3r360.
But is this work unique? Do not make her people far from programming? Of course they do! 3r360.
Any business and any part of it, including sales, are constantly engaged in building abstractions for customers who pay in money or something else for their materialization. If you look at it this way, then the whole economy is the heap of abstractions, desires and expectations of different people. 3r360.
But what is the difference? The difference is that it is abstracted. And if in programming everything is predetermined, but a huge number of combinations are allowed when building abstractions, then in economics it is becoming more and more difficult - the elements included in the abstracted subsystems and systems are people's aspirations and thoughts at a particular point in time, which are subject to almost any subsequent changes. , unlike the deterministic nature of computing devices. Determinism is ensured only by faith and conviction - exclusively by humanitarian categories, no matter how much someone believes in their technical essence. 3r360.
3r360.
Where do misunderstandings arise between business and programmers, and why are deadlines for projects being lost or why are business programmers not always successful? 3r360.
The answer lies in the fundamental rule of non-coincidence of abstractions. 3r360.
3r360.
Wrong definition of systems and subsystems, incorrect architectural design, changing customer requirements - do you know this? For almost all of these reasons, programmers and customers pour out almost the entire stream of indignation on each other. But is the decision made by the programmer regarding the construction of abstraction correct or incorrect in any case? Of course not. One can only say that the abstractions of one IT solution or architectural pattern satisfy or do not satisfy the abstractions of other systems and subsystems, including those built by people from business. 3r360.
The mismatch of abstractions at the level of systems and subsystems of software and hardware leads to runtime errors. 3r360.
But in the same way, the mismatch of business abstractions and programmer abstractions can bring everyone a lot of trouble. The discrepancy between the programmer and business abstractions leads to conflicts, the constant change of work by programmers, falling sales, revenue loss. 3r360.
The next main question is how long should the created abstractions exist? Should we vehemently defend them, defend, fight with others for the dominance of abstractions? Or do we choose the path of flexibility? 3r360.
3r360.
As you can see, these are almost always questions relating to a particular situation with concrete abstractions. 3r360.
And that is why programming is an art, and, moreover, humanitarian art. And it can be called a craft only in concrete and very limited (deterministic) situations in abstractions. In general, a person is not able to calculate or satisfy all possible abstractions, and is forced to make a choice between them, based on his outlook, for a selected period of time, after which they either successfully fit into the general abstraction or are rejected from it and replaced by others either remain untapped. 3r360.
3r360.
But it is necessary to live as it should, because it is shaky to revise all abstractions - this is very energy-intensive for the brain. 3r360.
That is why attempts are constantly being made to standardize and pre-design programming processes (waterflow), and then again roll back to statistical Agile methods. 3r360.
The same, and even more difficult, is happening in business. There, people are trying to come up with abstractions that are not embedded in other hard and guaranteeing abstractions, as in IT products, but on the contrary, trying to guess the abstractions of other people. 3r360.
Of course, business (and the state) follows the path of simplifying situations, introducing norms and rules. But their rigidity cannot be provided with anything, except as abstractions of people believing in them. 3r360.
3r360.
What is the conclusion to the programmer? 3r360.
3r360.
Do not get carried away with the outer shell of fashion trends, everything is fundamentally constant and it was always like this, and not only among programmers. Remember that you make any judgment, opinion, decision within the framework of abstractions built by you, but not only by you. If you have not verified this with other people's abstractions, including business abstractions, no matter how inhuman they may seem, this is your problem, and it's easier for you to solve it by changing your abstractions, trying to predict or exploring other people's abstractions. To change other people's abstractions, you need to take the path of the preacher and convert other people to faith in your abstractions. If you take this path, be prepared for even more complex abstraction management tasks besides programming. Be ready to negotiate and proselytize other people into general abstractions that will not have a deterministic basis and will be limited in time. Moreover, you may never find out why their faith lost or the abstraction changed. 3r360.
Limiting abstractions by force, by introducing rules for others, you take the path of war and destruction. And not the fact that during the war will not destroy yours. 3r360.
Remember that success will be only when different abstractions complement each other, creating a synergy effect.
3r366. ! function (e) {function t (t, n) {if (! (n in e)) {for (var r, a = e.document, i = a.scripts, o = i.length; o-- ;) if (-1! == i[o].src.indexOf (t)) {r = i[o]; break} if (! r) {r = a.createElement ("script"), r.type = "text /jаvascript", r.async =! ? r.defer =! ? r.src = t, r.charset = "UTF-8"; var d = function () {var e = a.getElementsByTagName ("script")[0]; e.parentNode.insertBefore (r, e)}; "[object Opera]" == e.opera? a.addEventListener? a.addEventListener ("DOMContentLoaded", d,! 1): e.attachEvent ("onload", d ): d ()}}} t ("//mediator.mail.ru/script/2820404/"""_mediator") () ();
3r360.
What is programming? This is an attempt to build a set of abstractions, turning many small details into a single object, and so on, according to the principle of the nested doll, to put everything into one big abstraction with properties and behavior. This is called a system, subsystem, etc. 3r360.
3r311. 3r360.
But is this work unique? Do not make her people far from programming? Of course they do! 3r360.
Any business and any part of it, including sales, are constantly engaged in building abstractions for customers who pay in money or something else for their materialization. If you look at it this way, then the whole economy is the heap of abstractions, desires and expectations of different people. 3r360.
But what is the difference? The difference is that it is abstracted. And if in programming everything is predetermined, but a huge number of combinations are allowed when building abstractions, then in economics it is becoming more and more difficult - the elements included in the abstracted subsystems and systems are people's aspirations and thoughts at a particular point in time, which are subject to almost any subsequent changes. , unlike the deterministic nature of computing devices. Determinism is ensured only by faith and conviction - exclusively by humanitarian categories, no matter how much someone believes in their technical essence. 3r360.
3r360.
Where do misunderstandings arise between business and programmers, and why are deadlines for projects being lost or why are business programmers not always successful? 3r360.
The answer lies in the fundamental rule of non-coincidence of abstractions. 3r360.
3r360.
Wrong definition of systems and subsystems, incorrect architectural design, changing customer requirements - do you know this? For almost all of these reasons, programmers and customers pour out almost the entire stream of indignation on each other. But is the decision made by the programmer regarding the construction of abstraction correct or incorrect in any case? Of course not. One can only say that the abstractions of one IT solution or architectural pattern satisfy or do not satisfy the abstractions of other systems and subsystems, including those built by people from business. 3r360.
The mismatch of abstractions at the level of systems and subsystems of software and hardware leads to runtime errors. 3r360.
But in the same way, the mismatch of business abstractions and programmer abstractions can bring everyone a lot of trouble. The discrepancy between the programmer and business abstractions leads to conflicts, the constant change of work by programmers, falling sales, revenue loss. 3r360.
The next main question is how long should the created abstractions exist? Should we vehemently defend them, defend, fight with others for the dominance of abstractions? Or do we choose the path of flexibility? 3r360.
3r360.
As you can see, these are almost always questions relating to a particular situation with concrete abstractions. 3r360.
And that is why programming is an art, and, moreover, humanitarian art. And it can be called a craft only in concrete and very limited (deterministic) situations in abstractions. In general, a person is not able to calculate or satisfy all possible abstractions, and is forced to make a choice between them, based on his outlook, for a selected period of time, after which they either successfully fit into the general abstraction or are rejected from it and replaced by others either remain untapped. 3r360.
3r360.
But it is necessary to live as it should, because it is shaky to revise all abstractions - this is very energy-intensive for the brain. 3r360.
That is why attempts are constantly being made to standardize and pre-design programming processes (waterflow), and then again roll back to statistical Agile methods. 3r360.
The same, and even more difficult, is happening in business. There, people are trying to come up with abstractions that are not embedded in other hard and guaranteeing abstractions, as in IT products, but on the contrary, trying to guess the abstractions of other people. 3r360.
Of course, business (and the state) follows the path of simplifying situations, introducing norms and rules. But their rigidity cannot be provided with anything, except as abstractions of people believing in them. 3r360.
3r360.
What is the conclusion to the programmer? 3r360.
3r360.
Do not get carried away with the outer shell of fashion trends, everything is fundamentally constant and it was always like this, and not only among programmers. Remember that you make any judgment, opinion, decision within the framework of abstractions built by you, but not only by you. If you have not verified this with other people's abstractions, including business abstractions, no matter how inhuman they may seem, this is your problem, and it's easier for you to solve it by changing your abstractions, trying to predict or exploring other people's abstractions. To change other people's abstractions, you need to take the path of the preacher and convert other people to faith in your abstractions. If you take this path, be prepared for even more complex abstraction management tasks besides programming. Be ready to negotiate and proselytize other people into general abstractions that will not have a deterministic basis and will be limited in time. Moreover, you may never find out why their faith lost or the abstraction changed. 3r360.
Limiting abstractions by force, by introducing rules for others, you take the path of war and destruction. And not the fact that during the war will not destroy yours. 3r360.
Remember that success will be only when different abstractions complement each other, creating a synergy effect.
3r366. ! function (e) {function t (t, n) {if (! (n in e)) {for (var r, a = e.document, i = a.scripts, o = i.length; o-- ;) if (-1! == i[o].src.indexOf (t)) {r = i[o]; break} if (! r) {r = a.createElement ("script"), r.type = "text /jаvascript", r.async =! ? r.defer =! ? r.src = t, r.charset = "UTF-8"; var d = function () {var e = a.getElementsByTagName ("script")[0]; e.parentNode.insertBefore (r, e)}; "[object Opera]" == e.opera? a.addEventListener? a.addEventListener ("DOMContentLoaded", d,! 1): e.attachEvent ("onload", d ): d ()}}} t ("//mediator.mail.ru/script/2820404/"""_mediator") () ();
