> Someone who focusses on a clean architecture even if it means slower development and less features This kills the company when their competition outdoes them

> Someone who focusses on a clean architecture even if it means slower development and less features This kills the company when their competition outdoes them. > or someone who will integrate nearly everything even if it means the code base, build process etc are a mess? This kills the company slightly slower, when technical debt means slower development and less features in the long run, allowing their competition to outdo them. > My feeling always says the first, but all my successes (which I define as "someone was getting his job done using my open source tool") came from the latter. So I wonder if my sample size is simply too small, or if I was too naive in the first place, thinking clean architecture is good and important. It's also possible your bar for "clean architecture" is high, or different from what others would consider "clean architecture". I have written some terrible, terrible code, that hasn't caused major problems. Either because it was replaced with a proper solution before growing too unwieldy, or because it was contained well enough that it never became unwieldy in the first place. You could say that even though the micro-architecture was terrible, the macro-architecture was at least acceptable - which IMO is the vastly more important of the two to keep "proper" for long term maintenance. Although one has to be wary of a system growing until the micro-architecture becomes macro-architecture, if the former is of poor quality.