It makes me think there is something fundamentally wrong with the way we write software.
You can imagine the fastest implementation of the loop is a single dev who knows their customers inside out and talks to them every day, has a flair for product design and works on a youthful and well architected code-base in a language they know extremely well.
In real life speed and quality of the loop are slowed down by:
1. The complexity of your organisations. Even in small companies once the engineer is out of earshot of the customer you rely on "Chinese Whispers" in the form of management, sales, product management, UI/UX, design guys etc. Its not due to incompetence, its just a very hard organisational problem whose solution depends on your company & market.
2. The existing complexity of your product. Products & underlying systems can be architected badly. This can make even trivial things difficult. It could be because of a lack of design knowledge (symptom: too many unused features), lack of systems knowledge (symptom: changing the colour on a website takes a day) or just a complex domain (eg tax accounting, financial services, crms etc)
I think you can trace back most other things (picking the wrong frameworks/languages, badly designed features, poor reliability, time taken with overhead like scrum & needless documentation etc) from the above two.
I can say this though, adding features comes at a cost. Not the programmer-cost of the feature though, all the other costs;
A) documentation. If it isn't documented, it doesn't exist. Good docs takes time and effort (and skill).
B) UI clutter. Most features require at least some UI to be added to the program. Menu item, check box, whatever. So 100 features later you have 100 little UI things, and it's starting to feel cluttered.
C) utility versus long-term maintainence. Add one more report, which only a tiny number of customers asked for (and none of them will actually use) and you will be updating that report _forever_. 100 reports like this later, and there's a lot of overhead.
D) training. Existing users will see this new UI. They need to be trained on it. Who's doing that? When?
E) overkill - simple programs appeal to people with simple needs. If Wordpad will do, the Word is overkill. Sometimes adding features means you're now targeting a different market, at a different price point.
F) security. Sure we can add JavaScript support. Not sure that's a good idea though. Features need to be thought-through from a security perspective.
G) price versus return. Sure it costs money to add this (plus all the above) - who's paying for that?
I could go on (translations, compatibility, partner products etc) but you get the picture...
We now have to run changes through legal to ensure global compliance as we're large enough to be a lawsuit target, especially in the EU where they're looking for US companies to make examples out of.
We have to run things through brand marketing and shared design teams to ensure we're acting as a consistent company despite actually being hundreds of teams. In fact, several years ago, we had a multi-year long initiative to introduce a single UI library across the company - before we had different UI design in different areas of our product.
One thing I find debatable is all the communication that takes several weeks or months before we can do anything. Getting all the stakeholders across different parts of the orgs together, incorporating their feedback, following up, etc. I think we could be nimbler in that regard and maybe some teams are.
There is of course added overhead of large engineering teams on older codebases, so development velocity slows but that feels more inevitable to me.
Project Managers can be hunting for quick wins to protect their own jobs, so they lead developers down stupid feature paths for the appearance of productivity rather than focusing on the great feature the company really needs, but that requires some focused work.
Managers are bad at assessing productivity, so they adopt bad processes (constant scrum meetings and the like) that can be draining towards motivation, purely to have some way to track people. And even when managers try and come up with some objective methods of measuring productivity, they're usually stupid ones; think of counting lines of code as an example.
Hiring enough employees is a big minefield. Managers are protecting their budgets and roles in an organization. What should become a relatively quick and simple process (have one technical leader pick a few promising resumes out of a pile, then have your devs talk to and pick the smartest people) can morph into an 18 step ordeal with lots of slow communication between half a dozen committees.
We've kind of conditioned every product manager that software is really hard and you can't just ask to change things without weeks/months of warnings or all the requirements up front.
At some point it is on us for over-complicating shit, and jumping from one new language/framework to the next. If you did more than what was necessary, and requirements change, then its on you.
Recent example: A new view of some data had to be added. So all that needs to be done is query the DB and return HTML with the correct styles. But the ORM used didn’t support ordering results with nulls last. So I had to add code to the ORM. The view doesn’t return HTML. Elements like <ul> are wrapped in a class. I had to modify the class constructor and render function to be able to return the HTML I needed, and modifying other code that used the class. In the end, what would have taken me 20 minutes took 2 hours. Was the ORM solving a real engineering or user problem? Nope. Were the view classes solving a problem? Ostensibly they were to make caching and testing easier, but none of that was actually happening. Most of my time wasn’t spent writing the code necessary to perform the task: an SQL query and constructing a string of HTML.
Something I noticed too that when there is simplicity, there is so many abstracted layers beneath that makes things slow, impossible to debug, and god help you if you if it doesn't do what you need. Things like React + Next.js. If you tried to follow the actual stack traces of what is going on underneath you would die.
2) A startup business only has a certain amount of runway available to survive. Delivering as fast as possible is very often a matter of survival. Delivering the most beautiful code too slowly means that your business fails.