Earlier quoted context omitted.
> the most egregious offenders are software developers Blame always rises. Management knows that any product without extensive review is going to be bad. They push it out the door without that review because quality costs. Stockholders know. Software is bad because you can't sue the companies that made it.
>Blame always rises. Management knows that any product without extensive review is going to be bad. They push it out the door without that review because quality costs. Stockholders know. Software is bad because you can't sue the companies that made it. I get that a variety of pressures are put on developers to add features and ship quickly. But whether it's corporate development done internally (e.g., LOB applicatio…
I love the architecture weenie role. It's tons of fun. But eventually you need to build something and only with experience do you discover the first set of complications, then marketing starts promising features and you've got the next, and management refuses to allocate more time.
Did you do something wrong at step 1 by building a prototype before knowing it would be perfect? And if so, how could you know that and what would you do to get there?
I write the code, and tag releases, but I don't determine what ships. I, and 95% of us, are not engineers and even those who are have abrogated their responsibility to make the bridge stand - we're all just building individual struts because someone told management that things done in a vacuum will all fit together properly in the end.
So I agree I guess, but don't at the same time.