[codingdave]

But how are you defining "equally bad"?

Lets ask what it means for tech work to be "bad". If I kept the business working, the tech evolving, while saving the business money and meeting every need it asked, including migration to new tech as the systems aged... which part is bad?

[nivertech]

1. Cowboy Coding - means no knowledge transfer, bus factor of 1 - bad for business.

2. Agile Manifesto says "working software over comprehensive documentation", which also leads to information silos and no knowledge transfer, and thus bad for business.

Did you ever inherited an enterprise project without any documentation, written in an esoteric language on a proprietary platform, with one-letter identifiers and without comments, and then the new management asking you to reverse engineer it and to explain to them what it does?

3. "Agile"/SAFe/Scrum are incentivizing short-term over long-term thinking. It's like picking up small-value coins on the street in front of a steamroller: you make small profits until you get wiped out. The Demo meetings are like Social Media dopamine injections - you feel good, but it's impossible to build something meaningful in a 1-3 weeks sprint.

[codingdave]

I think we agree on many things, but your comment makes me feel like you jumped from me being independent to assuming Cowboy Coding. You are assuming that because some enterprise systems are undocumented, that is what every enterprise coder does. The Agile Manifesto also is clear that putting one side above the other does not mean the other is not important.

FWIW, yes, I've taken over horrid undocumented systems... and figured them out, added documentation, and gotten them handed over into sustainable models. On the Agile side, I've been on startup teams that delivered amazing feature sets in a 3 week sprint, and did so sprint after sprint... but I've also been on teams who churned through sprints with nothing to show for it.

I don't think we can boil down a good vs. bad environment, or good vs. bad code, to SDLC processes or enterprise vs. startup. There are good teams, there are bad teams. And matching up the right environment and process to the right team can work wonders. But to be fair, most teams haven't found the right match.