{"id":370428,"date":"2024-05-21T04:24:54","date_gmt":"2024-05-21T04:24:54","guid":{"rendered":"http:\/\/savepearlharbor.com\/?p=370428"},"modified":"-0001-11-30T00:00:00","modified_gmt":"2024-05-21T04:24:54","slug":"","status":"publish","type":"post","link":"https:\/\/savepearlharbor.com\/?p=370428","title":{"rendered":"<span>Complexity in Software Engineering<\/span>"},"content":{"rendered":"<div><!--[--><!--]--><\/div>\n<div id=\"post-content-body\">\n<div>\n<div class=\"article-formatted-body article-formatted-body article-formatted-body_version-2\">\n<div xmlns=\"http:\/\/www.w3.org\/1999\/xhtml\">\n<p>This text is a compilation of author\u2019s experience, written to provide new juniour\/middle teammates the basis to start developing computational intensive or\/and ML based systems. It will take you about 5-10 minutes for reading, all mentioned terms will be referenced at the bottom.<\/p>\n<h2>Complexity<\/h2>\n<p>It\u2019s a common mistake, when people think software engineer have to only write a code and make features of a product. What makes this role really interesting is a Complexity. Constant fight with <a href=\"https:\/\/blog.softwaresuperglue.com\/tag\/technical-debt\/\" rel=\"noopener noreferrer nofollow\">entropy of systems<\/a> engineers are working on, reducing it as much as possible every day in that endless loop of knowledge and pain. Yeah, you get it right. Working on creation of new software especially noncommon one &#8212; is using new techs, products, instruments from day to day, and ofc getting some new unusual issues with them.<\/p>\n<p>To understand the concept we should discuss some terms at first.<\/p>\n<h4>Abstractions and links between them<\/h4>\n<p>We may consider our software as a system of actors\/subsystems\/submodules with some kind of relationships between them. Links between such elements can be:<\/p>\n<ul>\n<li>\n<p>hard &#8212; when you brake it, entire system will fall down<\/p>\n<\/li>\n<li>\n<p>soft &#8212; when you brake it, just a small part won\u2019t work, the system continue to operate, may be with reduced functionality<\/p>\n<\/li>\n<\/ul>\n<p><em>For example, Core in your product may depends on some external modules\/systems, but fallen dawn Billing or Metrics storage won\u2019t affect business critical functionality, your customers just won\u2019t be able to pay for smth for a while and your analytics won\u2019t get a portion of metrics.<\/em><\/p>\n<figure class=\"full-width\"><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/habrastorage.org\/r\/w780q1\/getpro\/habr\/upload_files\/563\/4cd\/21a\/5634cd21a495f36a27ba7beb29f18393.jpeg\" width=\"1778\" height=\"1265\" data-src=\"https:\/\/habrastorage.org\/getpro\/habr\/upload_files\/563\/4cd\/21a\/5634cd21a495f36a27ba7beb29f18393.jpeg\" data-blurred=\"true\"\/><\/figure>\n<p>And now, let\u2019s just think about how many items and their linkage <a href=\"https:\/\/phys.org\/news\/2009-11-brain-magic.html\" rel=\"noopener noreferrer nofollow\">average human can handle in mind simultaneously<\/a> &#8212; about 6-8 items and about 5-10 links between them. Quite enough to work with small systems: websites, scripts, simple crawlers may be some bots e.t.c.<\/p>\n<p>And what are you gonna do if your system is larger? I mean, large enough to not fit into your mind so you won\u2019t be able to operate abstractions and their links well enough. I guess, you will use such instruments as:<\/p>\n<ul>\n<li>\n<p>mind technics to remember more<\/p>\n<\/li>\n<li>\n<p>frameworks<\/p>\n<\/li>\n<li>\n<p>diagrams<\/p>\n<\/li>\n<li>\n<p>special software<\/p>\n<\/li>\n<\/ul>\n<p>So, all above &#8212; just to handle complex relationships between elements of just one system. And let\u2019s imagine forward &#8212; several complex systems which should communicate with each other. But keep in mind &#8212; these systems\/subsystems are not a static picture. They constantly interact either with users either with developers and engineers.<\/p>\n<blockquote>\n<p>Usual processes and users interactions in a software system will appear in about 3-10 months of development and growth.<\/p>\n<\/blockquote>\n<h4>Wave of changes<\/h4>\n<figure class=\"full-width\"><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/f55\/434\/44c\/f5543444cf1c6941e21e997d7bac46a2.png\" width=\"2000\" height=\"1333\" data-src=\"https:\/\/habrastorage.org\/getpro\/habr\/upload_files\/f55\/434\/44c\/f5543444cf1c6941e21e997d7bac46a2.png\"\/><\/figure>\n<p>But why to do it, why you need to keep in mind all this stuff, is it necessary in a daily routines? Short answer &#8212; yes. As software is usually just an automation of business processes, it mirrors some nature of business from inside. And the most important &#8212; starve for constant growing and adaptation to environment and market changes. To be able to survive in a market, business should constantly evolve and improve itself, so either its software should be updated, fixed, refactored, improved and optimized.<\/p>\n<blockquote>\n<p>There is no talks here about non working software at all. Your system should be able to operate at least.<\/p>\n<\/blockquote>\n<p>And now we approaching to one of a major points: it\u2019s not essential how well your software is and how beautiful you wrote a code, or make it in a few lines instead of several pages. It just need to work as business demands. And it\u2019s only a software engineer\u2019s responsibility to think about how easily it can be changed and improved during timeline. Usually business don\u2019t give a though about it in a short term, and will only start crying about it in a long term. So, the cost of change &#8212; what\u2019s important. How adding new feature will affect old ones, how optimization of that will affect costs in maintenance time of another part and so on.<\/p>\n<h4>Forgotten realms<\/h4>\n<p>How to understand that you have a complex system, not a small one like a project, but a real bitch? There is a very simple answer &#8212; just when you need more than one human to work on it.<\/p>\n<p>And there are signs you already have complexity problems:<\/p>\n<ul>\n<li>\n<p>there is a person, who only keep in mind some information about a subsystem\/submodule of a software. No one else know about it enough to operate with.<\/p>\n<\/li>\n<li>\n<p>nobody knows a \u201cwhole picture\u201d of your IT landscape, every engineer operates only with own slice of  knowledge about an entire system.<\/p>\n<\/li>\n<li>\n<p>engineers leave and at sometimes you heard from a colleague \u201cdon\u2019t know what\u2019s happen there\u201d, \u201cit\u2019s a black box for me\u201d<\/p>\n<\/li>\n<\/ul>\n<figure class=\"full-width\"><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/habrastorage.org\/r\/w780q1\/getpro\/habr\/upload_files\/d78\/482\/2c7\/d784822c77b1fdd4db38a2137f5d0943.jpeg\" width=\"1755\" height=\"1281\" data-src=\"https:\/\/habrastorage.org\/getpro\/habr\/upload_files\/d78\/482\/2c7\/d784822c77b1fdd4db38a2137f5d0943.jpeg\" data-blurred=\"true\"\/><\/figure>\n<h4>Vortex of doom<\/h4>\n<p>What happens if business didn\u2019t allow its engineers to spent enough time to fight a complexity?<\/p>\n<p>There is a very similar phenomenon in a biology, called an <a href=\"https:\/\/en.wikipedia.org\/wiki\/Ant_mill\" rel=\"noopener noreferrer nofollow\">Ant Mill<\/a> &#8212; due to some reason ants lost their pheromone tracks and started following nearest fellows ant forming constantly rotating circle. More and more ants join this circle till large group of them involved. Then they will run till their death.<\/p>\n<p>So, the same is for human companies &#8212; there is a critical mass of tech debt (different for each company), after reaching it\u2019ll begin a circle of:<\/p>\n<ul>\n<li>\n<p>01: bug fixing<\/p>\n<\/li>\n<li>\n<p>02: making new bugs while fixing old ones<\/p>\n<\/li>\n<li>\n<p>03: go to 01<\/p>\n<\/li>\n<\/ul>\n<p>And will last till engineers leave such doomed company at all.<\/p>\n<figure class=\"full-width\"><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/ec1\/3f7\/440\/ec13f7440f08aa2894189e2e38503faf.png\" width=\"1200\" height=\"628\" data-src=\"https:\/\/habrastorage.org\/getpro\/habr\/upload_files\/ec1\/3f7\/440\/ec13f7440f08aa2894189e2e38503faf.png\"\/><\/figure>\n<h2>Ways to fight it<\/h2>\n<p>There is no way to keep complexity at a low level long time. It\u2019s a constant process and require some balance of spending time\/money on developing new feature and refactoring an old ones.<\/p>\n<p>It\u2019s more like a hygiene &#8212; you just need to do it constantly every period of time. Another analogy &#8212; <a href=\"https:\/\/en.wikipedia.org\/wiki\/Second_law_of_thermodynamics\" rel=\"noopener noreferrer nofollow\">second law of thermodynamics<\/a>, when you should spent some energy on a system to not let its entropy grow. So what are basic ways to reduce a complexity?<\/p>\n<h3>Human in the loop<\/h3>\n<h4>Rules and conventions<\/h4>\n<p>Engineers tend to follow some common rules and conventions made inside a company or outside whatever. Usually it\u2019s:<\/p>\n<ul>\n<li>\n<p>best practices documents, like <a href=\"https:\/\/google.github.io\/eng-practices\/\" rel=\"noopener noreferrer nofollow\">this one<\/a><\/p>\n<\/li>\n<li>\n<p>manifestos, like <a href=\"http:\/\/programming-motherfucker.com\/\" rel=\"noopener noreferrer nofollow\">this one<\/a> or <a href=\"https:\/\/www.agilealliance.org\/agile101\/the-agile-manifesto\/\" rel=\"noopener noreferrer nofollow\">this one<\/a><\/p>\n<\/li>\n<li>\n<p>code style, which usually should be taken from big tech companies, like <a href=\"https:\/\/google.github.io\/styleguide\/\" rel=\"noopener noreferrer nofollow\">Google<\/a>, <a href=\"https:\/\/aws.github.io\/amazon-freertos\/202107.00\/c-sdk\/main\/guide_developer_styleguide.html\" rel=\"noopener noreferrer nofollow\">Amazon<\/a>, <a href=\"https:\/\/netflixtechblog.com\/how-we-build-code-at-netflix-c5d9bd727f15\" rel=\"noopener noreferrer nofollow\">Netflix<\/a> and so on<\/p>\n<\/li>\n<li>\n<p>gitflow policies<\/p>\n<\/li>\n<li>\n<p>any other agreements between people to collaborate effectively<\/p>\n<\/li>\n<\/ul>\n<h4>Organizational structures<\/h4>\n<p>Hierarchy helps to scale people work and do changes in parallel.<\/p>\n<p>It depends which way is optimal for a company in its actual situation. Better to read <a href=\"https:\/\/en.wikipedia.org\/wiki\/Reinventing_Organizations\" rel=\"noopener noreferrer nofollow\">this book<\/a> to understand deeper:<\/p>\n<ul>\n<li>\n<p>in red companies they usually build vertical hierarchy to react faster, tradeoff &#8212; lack of creativity among developers\/engineers<\/p>\n<\/li>\n<li>\n<p>in green companies there are more horizontal structures with much creativity and agility, tradeoff &#8212; lack of speed<\/p>\n<\/li>\n<\/ul>\n<h3>Software to the rescue<\/h3>\n<h4>IDE<\/h4>\n<p>Intellesense, autosuggestion, copilot &#8212; all of these instruments help engineers to handle more abstractions and links between them at once.<\/p>\n<h4>The price of automation<\/h4>\n<p>QA checks, CI\/CD &#8212; all of that makes systems and development processes more inert in a small group of engineers, but let you scale your development up to multiple teams.<\/p>\n<h4>Observability<\/h4>\n<p>Monitoring, logging, error capturing help a lot.<\/p>\n<p>Here are the helpfullest ones:<\/p>\n<ul>\n<li>\n<p><a href=\"https:\/\/sentry.io\/\" rel=\"noopener noreferrer nofollow\">Sentry<\/a><\/p>\n<\/li>\n<li>\n<p><a href=\"https:\/\/grafana.com\/\" rel=\"noopener noreferrer nofollow\">https:\/\/grafana.com\/<\/a><\/p>\n<\/li>\n<li>\n<p><a href=\"https:\/\/www.elastic.co\/blog\/elasticsearch-free-open-limitless\" rel=\"noopener noreferrer nofollow\">https:\/\/www.elastic.co\/blog\/elasticsearch-free-open-limitless<\/a><\/p>\n<\/li>\n<\/ul>\n<h2>Total<\/h2>\n<ol>\n<li>\n<p>Software is a non-static system being affected by constant changes.<\/p>\n<\/li>\n<li>\n<p>Software and development process should be considered as indivisible concept. You mustn\u2019t solve some software problems without thinking about a process and vice versa.<\/p>\n<\/li>\n<li>\n<p>System complexity problem is more noticeable on a scale: scale of people, hardware and system load.<\/p>\n<\/li>\n<\/ol>\n<p>author: Andrey Avdeev, <a href=\"http:\/\/aavdeev.com\" rel=\"noopener noreferrer nofollow\">aavdeev.com<\/a> <\/p>\n<p>editor: Maksim Sidorov<\/p>\n<\/p>\n<\/div>\n<\/div>\n<\/div>\n<p><!----><!----><\/div>\n<p><!----><!----><br \/> \u0441\u0441\u044b\u043b\u043a\u0430 \u043d\u0430 \u043e\u0440\u0438\u0433\u0438\u043d\u0430\u043b \u0441\u0442\u0430\u0442\u044c\u0438 <a href=\"https:\/\/habr.com\/ru\/articles\/799265\/\"> https:\/\/habr.com\/ru\/articles\/799265\/<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<div><!--[--><!--]--><\/div>\n<div id=\"post-content-body\">\n<div>\n<div class=\"article-formatted-body article-formatted-body article-formatted-body_version-2\">\n<div xmlns=\"http:\/\/www.w3.org\/1999\/xhtml\">\n<p>This text is a compilation of author\u2019s experience, written to provide new juniour\/middle teammates the basis to start developing computational intensive or\/and ML based systems. It will take you about 5-10 minutes for reading, all mentioned terms will be referenced at the bottom.<\/p>\n<h2>Complexity<\/h2>\n<p>It\u2019s a common mistake, when people think software engineer have to only write a code and make features of a product. What makes this role really interesting is a Complexity. Constant fight with <a href=\"https:\/\/blog.softwaresuperglue.com\/tag\/technical-debt\/\" rel=\"noopener noreferrer nofollow\">entropy of systems<\/a> engineers are working on, reducing it as much as possible every day in that endless loop of knowledge and pain. Yeah, you get it right. Working on creation of new software especially noncommon one &#8212; is using new techs, products, instruments from day to day, and ofc getting some new unusual issues with them.<\/p>\n<p>To understand the concept we should discuss some terms at first.<\/p>\n<h4>Abstractions and links between them<\/h4>\n<p>We may consider our software as a system of actors\/subsystems\/submodules with some kind of relationships between them. Links between such elements can be:<\/p>\n<ul>\n<li>\n<p>hard &#8212; when you brake it, entire system will fall down<\/p>\n<\/li>\n<li>\n<p>soft &#8212; when you brake it, just a small part won\u2019t work, the system continue to operate, may be with reduced functionality<\/p>\n<\/li>\n<\/ul>\n<p><em>For example, Core in your product may depends on some external modules\/systems, but fallen dawn Billing or Metrics storage won\u2019t affect business critical functionality, your customers just won\u2019t be able to pay for smth for a while and your analytics won\u2019t get a portion of metrics.<\/em><\/p>\n<figure class=\"full-width\"><\/figure>\n<p>And now, let\u2019s just think about how many items and their linkage <a href=\"https:\/\/phys.org\/news\/2009-11-brain-magic.html\" rel=\"noopener noreferrer nofollow\">average human can handle in mind simultaneously<\/a> &#8212; about 6-8 items and about 5-10 links between them. Quite enough to work with small systems: websites, scripts, simple crawlers may be some bots e.t.c.<\/p>\n<p>And what are you gonna do if your system is larger? I mean, large enough to not fit into your mind so you won\u2019t be able to operate abstractions and their links well enough. I guess, you will use such instruments as:<\/p>\n<ul>\n<li>\n<p>mind technics to remember more<\/p>\n<\/li>\n<li>\n<p>frameworks<\/p>\n<\/li>\n<li>\n<p>diagrams<\/p>\n<\/li>\n<li>\n<p>special software<\/p>\n<\/li>\n<\/ul>\n<p>So, all above &#8212; just to handle complex relationships between elements of just one system. And let\u2019s imagine forward &#8212; several complex systems which should communicate with each other. But keep in mind &#8212; these systems\/subsystems are not a static picture. They constantly interact either with users either with developers and engineers.<\/p>\n<blockquote>\n<p>Usual processes and users interactions in a software system will appear in about 3-10 months of development and growth.<\/p>\n<\/blockquote>\n<h4>Wave of changes<\/h4>\n<figure class=\"full-width\"><\/figure>\n<p>But why to do it, why you need to keep in mind all this stuff, is it necessary in a daily routines? Short answer &#8212; yes. As software is usually just an automation of business processes, it mirrors some nature of business from inside. And the most important &#8212; starve for constant growing and adaptation to environment and market changes. To be able to survive in a market, business should constantly evolve and improve itself, so either its software should be updated, fixed, refactored, improved and optimized.<\/p>\n<blockquote>\n<p>There is no talks here about non working software at all. Your system should be able to operate at least.<\/p>\n<\/blockquote>\n<p>And now we approaching to one of a major points: it\u2019s not essential how well your software is and how beautiful you wrote a code, or make it in a few lines instead of several pages. It just need to work as business demands. And it\u2019s only a software engineer\u2019s responsibility to think about how easily it can be changed and improved during timeline. Usually business don\u2019t give a though about it in a short term, and will only start crying about it in a long term. So, the cost of change &#8212; what\u2019s important. How adding new feature will affect old ones, how optimization of that will affect costs in maintenance time of another part and so on.<\/p>\n<h4>Forgotten realms<\/h4>\n<p>How to understand that you have a complex system, not a small one like a project, but a real bitch? There is a very simple answer &#8212; just when you need more than one human to work on it.<\/p>\n<p>And there are signs you already have complexity problems:<\/p>\n<ul>\n<li>\n<p>there is a person, who only keep in mind some information about a subsystem\/submodule of a software. No one else know about it enough to operate with.<\/p>\n<\/li>\n<li>\n<p>nobody knows a \u201cwhole picture\u201d of your IT landscape, every engineer operates only with own slice of  knowledge about an entire system.<\/p>\n<\/li>\n<li>\n<p>engineers leave and at sometimes you heard from a colleague \u201cdon\u2019t know what\u2019s happen there\u201d, \u201cit\u2019s a black box for me\u201d<\/p>\n<\/li>\n<\/ul>\n<figure class=\"full-width\"><\/figure>\n<h4>Vortex of doom<\/h4>\n<p>What happens if business didn\u2019t allow its engineers to spent enough time to fight a complexity?<\/p>\n<p>There is a very similar phenomenon in a biology, called an <a href=\"https:\/\/en.wikipedia.org\/wiki\/Ant_mill\" rel=\"noopener noreferrer nofollow\">Ant Mill<\/a> &#8212; due to some reason ants lost their pheromone tracks and started following nearest fellows ant forming constantly rotating circle. More and more ants join this circle till large group of them involved. Then they will run till their death.<\/p>\n<p>So, the same is for human companies &#8212; there is a critical mass of tech debt (different for each company), after reaching it\u2019ll begin a circle of:<\/p>\n<ul>\n<li>\n<p>01: bug fixing<\/p>\n<\/li>\n<li>\n<p>02: making new bugs while fixing old ones<\/p>\n<\/li>\n<li>\n<p>03: go to 01<\/p>\n<\/li>\n<\/ul>\n<p>And will last till engineers leave such doomed company at all.<\/p>\n<figure class=\"full-width\"><\/figure>\n<h2>Ways to fight it<\/h2>\n<p>There is no way to keep complexity at a low level long time. It\u2019s a constant process and require some balance of spending time\/money on developing new feature and refactoring an old ones.<\/p>\n<p>It\u2019s more like a hygiene &#8212; you just need to do it constantly every period of time. Another analogy &#8212; <a href=\"https:\/\/en.wikipedia.org\/wiki\/Second_law_of_thermodynamics\" rel=\"noopener noreferrer nofollow\">second law of thermodynamics<\/a>, when you should spent some energy on a system to not let its entropy grow. So what are basic ways to reduce a complexity?<\/p>\n<h3>Human in the loop<\/h3>\n<h4>Rules and conventions<\/h4>\n<p>Engineers tend to follow some common rules and conventions made inside a company or outside whatever. Usually it\u2019s:<\/p>\n<ul>\n<li>\n<p>best practices documents, like <a href=\"https:\/\/google.github.io\/eng-practices\/\" rel=\"noopener noreferrer nofollow\">this one<\/a><\/p>\n<\/li>\n<li>\n<p>manifestos, like <a href=\"http:\/\/programming-motherfucker.com\/\" rel=\"noopener noreferrer nofollow\">this one<\/a> or <a href=\"https:\/\/www.agilealliance.org\/agile101\/the-agile-manifesto\/\" rel=\"noopener noreferrer nofollow\">this one<\/a><\/p>\n<\/li>\n<li>\n<p>code style, which usually should be taken from big tech companies, like <a href=\"https:\/\/google.github.io\/styleguide\/\" rel=\"noopener noreferrer nofollow\">Google<\/a>, <a href=\"https:\/\/aws.github.io\/amazon-freertos\/202107.00\/c-sdk\/main\/guide_developer_styleguide.html\" rel=\"noopener noreferrer nofollow\">Amazon<\/a>, <a href=\"https:\/\/netflixtechblog.com\/how-we-build-code-at-netflix-c5d9bd727f15\" rel=\"noopener noreferrer nofollow\">Netflix<\/a> and so on<\/p>\n<\/li>\n<li>\n<p>gitflow policies<\/p>\n<\/li>\n<li>\n<p>any other agreements between people to collaborate effectively<\/p>\n<\/li>\n<\/ul>\n<h4>Organizational structures<\/h4>\n<p>Hierarchy helps to scale people work and do changes in parallel.<\/p>\n<p>It depends which way is optimal for a company in its actual situation. Better to read <a href=\"https:\/\/en.wikipedia.org\/wiki\/Reinventing_Organizations\" rel=\"noopener noreferrer nofollow\">this book<\/a> to understand deeper:<\/p>\n<ul>\n<li>\n<p>in red companies they usually build vertical hierarchy to react faster, tradeoff &#8212; lack of creativity among developers\/engineers<\/p>\n<\/li>\n<li>\n<p>in green companies there are more horizontal structures with much creativity and agility, tradeoff &#8212; lack of speed<\/p>\n<\/li>\n<\/ul>\n<h3>Software to the rescue<\/h3>\n<h4>IDE<\/h4>\n<p>Intellesense, autosuggestion, copilot &#8212; all of these instruments help engineers to handle more abstractions and links between them at once.<\/p>\n<h4>The price of automation<\/h4>\n<p>QA checks, CI\/CD &#8212; all of that makes systems and development processes more inert in a small group of engineers, but let you scale your development up to multiple teams.<\/p>\n<h4>Observability<\/h4>\n<p>Monitoring, logging, error capturing help a lot.<\/p>\n<p>Here are the helpfullest ones:<\/p>\n<ul>\n<li>\n<p><a href=\"https:\/\/sentry.io\/\" rel=\"noopener noreferrer nofollow\">Sentry<\/a><\/p>\n<\/li>\n<li>\n<p><a href=\"https:\/\/grafana.com\/\" rel=\"noopener noreferrer nofollow\">https:\/\/grafana.com\/<\/a><\/p>\n<\/li>\n<li>\n<p><a href=\"https:\/\/www.elastic.co\/blog\/elasticsearch-free-open-limitless\" rel=\"noopener noreferrer nofollow\">https:\/\/www.elastic.co\/blog\/elasticsearch-free-open-limitless<\/a><\/p>\n<\/li>\n<\/ul>\n<h2>Total<\/h2>\n<ol>\n<li>\n<p>Software is a non-static system being affected by constant changes.<\/p>\n<\/li>\n<li>\n<p>Software and development process should be considered as indivisible concept. You mustn\u2019t solve some software problems without thinking about a process and vice versa.<\/p>\n<\/li>\n<li>\n<p>System complexity problem is more noticeable on a scale: scale of people, hardware and system load.<\/p>\n<\/li>\n<\/ol>\n<p>author: Andrey Avdeev, <a href=\"http:\/\/aavdeev.com\" rel=\"noopener noreferrer nofollow\">aavdeev.com<\/a> <\/p>\n<p>editor: Maksim Sidorov<\/p>\n<\/p>\n<\/div>\n<\/div>\n<\/div>\n<p><!----><!----><\/div>\n<p><!----><!----><br \/> \u0441\u0441\u044b\u043b\u043a\u0430 \u043d\u0430 \u043e\u0440\u0438\u0433\u0438\u043d\u0430\u043b \u0441\u0442\u0430\u0442\u044c\u0438 <a href=\"https:\/\/habr.com\/ru\/articles\/799265\/\"> https:\/\/habr.com\/ru\/articles\/799265\/<\/a><br \/><\/br><\/br><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[],"tags":[],"class_list":["post-370428","post","type-post","status-publish","format-standard","hentry"],"_links":{"self":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/posts\/370428","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=370428"}],"version-history":[{"count":0,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/posts\/370428\/revisions"}],"wp:attachment":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=370428"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=370428"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=370428"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}