So what is more important to have: (1) a product with bugs which can be sold and raises money, (2) a piece of software that has no bugs but also shipped x-times as late thus only learns you your true requirements x-times as late.
For someone bashing on ivory tower architects in the subsequent lines this sounds like pure irony. The mythical software engineer that doesn't produce bugs.
> Most defects in software come from poor engineering.
In my experience most defects come from not knowing the exact way your software will be used by the customer. Sometimes because of not asking thoroughly but more often because the customer doesn't know yet exactly. Also in my experience most bugs are actually change requests in disguise. Actions that you didn't imagine and never designed your software for but are executed by the customer and now cause trouble to your software.
> Oh and yes, design, architecture and other fancy words, are just engineering in the software industry, because it is not mature enough to have that level of abstraction, in which the architect draws the picture and the engineer implements it in such a way that it almost 100% of the time is right on the money. No. Far from it. What happens in reality is that the engineers try desperately to make the system work somehow, while maintaining the illusion of the story told by the architect.
I feel sorry for your loss. You must have worked in awful environments to think about it this way.
The next few sections I skimmed through read like the author is not proficient in software engineering at all which make me doubt if this is experience from some coding (scripting) side-projects rather than a full-time professional software engineer.