I'd also be interested. Some drivers of complexity I would think of:

* Using many of the GoF/OOP patterns, because you may need extensibility at some point. Basically YAGNI.

* Complex, hard to mentally map, build systems (e.g. CMake).

* Designing for purity over simplicity (I'm actually big on FP, here I'm thinking of the Haskell crowd which IMHO sometimes overdoes it).

* Writing a complex architecture without prototyping. Often your prototype will tell you what you need. If you start architecting too much beforehand then you often waste time on some details that don't matter, and even worse, afterwards you try to force it into your architecture which doesn't actually fit the problem. The beauty of software is that it's easy to change things. Architecture on buildings is different because you need to make sure that you're not building the wrong thing. In software building the wrong thing can give you the right insights and still be faster than planning for every eventuality.

> Writing a complex architecture without prototyping. Often your prototype will tell you what you need.

One million times yes. In my experience using a prototype as an input to a specification works much better than the other way around.

> Complex, hard to mentally map, build systems (e.g. CMake).

Also yes. It's almost to the point where one has to understand every detail of how CMake works to get it to do one (1) specific thing you need in your build process.

* Splitting requirements documents into user stories and then evolving the document further. This practice can be improved upon by adding redundancy with attaching the document to user stories and enterprise wiki. Further optimization can get to the org to CMMI level 5 but requires investment in diversity of the most critical requirements in other locations and protection of these assets from being linked.

Nah, that's OK. Thanks.

Just to clarify. I have been down this road. I am not interested in sacred cows or third rails.

I'm trying to do all my writing and commenting, based only on my own experience and insight.

I'm done with fighting on the Internet. I don't have the energy for it anymore.

I can respect that. Although I would have liked to hear your take on it, I know what you mean.

Agile and Scrum can add a lot of meetings and processes and metrics into a development team. For non-technical managers this is great because they can create nice charts with story points for upper management.

The above comment can devolve into a flame war because non-technical managers see Agile and Scrum in a different light. They believe that without proper management developers will be unproductive.

I can't believe I forgot this one. Scrum is so terrible, I don't know why it's still being introduced.

I'm always happy to chat (pontificate in an "OK Boomer" kind of way, I guess), but not in public forums. My screen name applies in a lot of places.