[codingdave]

This list seems to carry a heap of bias with it. Enterprise cares about what works for them, and quick-and-dirty is just fine. Startups care about what works for a broader customer base and need higher quality. Different needs, and different styles. Neither approach is wrong... but they serve different purposes and will appear like cruddy work if you put an enterprise approach into the startup world. And vice versa.

The one point which seems completely wrong is #9 - I've never seen agile-hamster-wheel-rituals bog down an enterprise shop. I've seen the other extreme, where in an enterprise, platforms are dealt out to the devs like a deck of cards, and as long as you keep your platforms running and working for the business, your manager barely even checks in with you. I'd easily go days, often weeks, and sometimes even months without any discussions at all with my boss.

[P_I_Staker]

Worth re-iterating that OP was just explaining the various bias and stereotypes. I think the comment speaks more to perception than reality. There really isn't any good reason to think open source good, closed source bad.

I will say that source control is one area where enterprise is almost total garbage, probably for some of the reasons listed (as well as a lot of unlisted reasons like customers being scared of change). There's probably many other examples where this holds true, and some where it doesn't.

[nivertech]

> The one point which seems completely wrong is #9 - I've never seen agile-hamster-wheel-rituals bog down an enterprise shop. I've seen the other extreme, where in an enterprise, platforms are dealt out to the devs like a deck of cards, and as long as you keep your platforms running and working for the business, your manager barely even checks in with you. I'd easily go days, often weeks, and sometimes even months without any discussions at all with my boss.

I've seen it all. At one place it went from Cowboy Coding where you were left to your own devices for months, straight to SAFe/Scrum/standups;) Both are equally bad and no match to RUP, informal mini-waterfall (think->design->build(iterate)->ship) or Shape Up method.

[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.