# 2021 Winding Down: Software Complexity, Inconsistency, and Outsourcing

DevFeed: [2021 Winding Down: Software Complexity, Inconsistency, and Outsourcing](<https://devfeed.tech/articles/2021-winding-down-22380.md>)

Original publisher: [Read original article](<https://www.red-lang.org/2021/12/2021-winding-down.html>)

Author: Unknown (noreply@blogger.com)

Published: 2021-12-31T20:23:00Z

Content type: opinion

Language: en

Sources: [Red](<https://devfeed.tech/sources/red.md>)

Topics: [systems](<https://devfeed.tech/topics/systems.md>), [consistency](<https://devfeed.tech/topics/consistency.md>), [Software](<https://devfeed.tech/topics/software.md>), [Logging](<https://devfeed.tech/topics/logging.md>), [coding](<https://devfeed.tech/topics/coding.md>), [Tool](<https://devfeed.tech/topics/tool.md>)

Tags: [apis](<https://devfeed.tech/tags/apis.md>), [article](<https://devfeed.tech/tags/article.md>), [blog](<https://devfeed.tech/tags/blog.md>), [blog-post](<https://devfeed.tech/tags/blog-post.md>), [complexity](<https://devfeed.tech/tags/complexity.md>), [consistency](<https://devfeed.tech/tags/consistency.md>), [developer](<https://devfeed.tech/tags/developer.md>), [logging](<https://devfeed.tech/tags/logging.md>), [software](<https://devfeed.tech/tags/software.md>)

## AI overview

A Red project blog post reflects on software complexity, arguing that outsourcing simple features and accumulating libraries can create inconsistent environments. It also discusses the shift from libraries toward APIs and service-based companies, along with the associated dependency risks.

## Source excerpt

Another quarter, another blog post. Seems almost rushed after the previous drought. To set the stage, I'll start with a bit of a rant about complexity. If you just want the meat of what's happening in the Red world, feel free to skip the introduction. Complexity Considerations: Part 1 I liked what the InfoWorld article, Complexity is Killing Software Developers said, which we all know, about difficult domains (voice and image recognition, etc.) being available as APIs. This lets us tackle things we couldn't in some cases. Though I imagine @dockimbel or others also used Dragon Dictate's libraries back in the 90s. What we have now is massive data to train systems like that. Those work well, allowing us to add features we otherwise couldn't with a small team. The problem I see is that the trend has become for everything to be outsourced, including simple features like logging, and those libraries have exploded. There must be graphs available to show the change. Moderately complex domains, UIs for example, have risen in number and lead to what @hiiamboris says about Brownian Movement. It's a random collection of things, not designed to work together, without a coherent vision. A quote from the above article says it this way: "Complexity is less the issue than inconsistency in an environment." It used to be that you could take a FORTRAN, COBOL, Lisp, VB, Pascal/Delphi, Access/PowerBuilder, dBase/Clipper/Paradox, or even a Java developer, drop them into a project, and they could work from a solid core, learning the team's custom bits and any commercial tools as they went. With JS leading the way, but not alone in this, a programmer can only rely on a much smaller core, relative to how many libraries are used. Because those libraries, and the choices to use a particular combination of them were not designed to work together, there is no guarantee (or perhaps hope) of consistency to leverage. It's worse if you came from a history of other tools that were based on different