> In theory, systems can be built such that changes and updates are simple configuration changes, including new features. Taken to the extreme, that's a low co

> In theory, systems can be built such that changes and updates are simple configuration changes, including new features. Taken to the extreme, that's a low code platform. However, the complexity I am speaking of is the intersection of what a product should do today, what it does do today, what it should do tomorrow, and what technical debt prevents this from being obvious. (For example, if the system has grown in a way that what was one team is now four and they are all trying to work in an intermingled codebase that made sense in a smaller organization.) The solution may be 1,000 lines of code, but it takes the analysis from someone who provides a 1,000 line rather than a 10,000 line solution. That 1,000 lines might even be obvious once the problem is defined. A senior developer, in this case, is someone for whom the mechanical translation of an idea to code is not the limiting part. > So while any given feature could be coded by multiple teams of mid-level skill, it could also be coded by a small team of high level engineers. That's entirely true. However, there are more organizations than high level engineers. And how do you manage to build those high level engineers if all we (as an industry) do is keep hiring from a small group?