[nivertech]

There are so many reasons for this. Here are some of them that I can write without much thinking or checking my notes.

1. Enterprise problem domains are usually much more complex than the ones which are targeted by the OSS.

2. Enterprise problem domains are full of unclear, wrong and even contradicting requirements.

3. Enterprises usually have lots of legacy code/systems.

4. Enterprises usually have lots of glue code duct-taping various internal systems.

5. If nobody will see your code publicly, then you have less incentive to invest in its UX/DX/documentation/code quality/etc. You incentivized to take shortcuts and use quick-and-dirty solutions.

6. Even though usually enterprises have internal SQA teams, it's no match to many testers in the open-source world. Internal SW is only deployed in a single environment/platform and tested with the happy path only. OSS is tested in lots of different environments/platforms with lots of edge cases.

7. Unlike the OSS world, the developers working in enterprises are usually 9-5ers, working-to-live, not living-to-work.

8. The quality/skill level of developers is usually lower. They're usually become experts in their business domain, but their coding skills may remain on the "advanced beginner" level.

9. They usually working under micromanagement-like SDLCs which impede their productivity and code quality: "Agile"/SAFe/Scrum/daily standups.

Some of the things I wrote might be anecdotes or stereotypes, so certainly not all enterprise developers are like this.

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