> usually at least two to three generations behind on every technological trend
It's easy to refactor (or completely rewrite) for whatever the hot new fad is when you're dealing with small codebases (<100k loc) that haven't been around very long and most likely won't continue to be in use for long. That's not productive when you're working on a product that has millions of lines of code and has been in use for years (and most likely will continue to be so).
It has nothing to do with "pointy haired bosses" - believe it or not a lot of us [enterprise developers] care more about actually getting stuff done then bragging to our friends how we're playing with whatever is hip this week.
I think that's a valid point but it only explains a small fraction of the ugliness of enterprise software. It explains why it tends to trend a bit behind, but it does not explain why you need 2gb of RAM to run a web application server or why you need ten pages of XML vomit to add a record to a database. Those kinds of things smack of over-engineering (usually via premature generalization and "architecture astronautism") and cargo cultism among other things. When I look at those systems and code bases I always just sit there and ask "what problem does this solve? what problem does this solve? what problem does this solve?"
I also didn't mean to imply that there are no good developers in "enterprise." But I do believe that "enterprise" is to good developers what, say, a corrupt economy is to good entrepreneurs. You can operate there but it's painful and everything about it gets in the way of doing the right thing.
Also also (heh) I didn't mean to imply that all enterprises are "enterprise." That's why I put it in quotes. Some large organizations manage to avoid these pathologies. I've even seen really excellent systems emerge from government labs if the people running them are clueful. "Enterprise" in quotes refers to the pathologies that afflict big over-priced over-engineered slow clunky UX abominations. Everyone's seen them and everyone's been forced to use them... forced because nobody would ever voluntarily do so.
> You can operate there but it's painful and everything about it gets in the way of doing the right thing
Yikes, that hit close to home. Where I'm working now is very "enterprise", but when they brought me on they gave me a huge amount of autonomy and it's worked out great for them- I started fresh on new projects and was able to make them lightweight, fast, and pretty.
And then they toss at me a behemoth of an ancient, 10-year-old project with services that connect to services that connect to services (all on the same machine!) and probably uses more than 2GB of RAM for simple CRUD screens. There's no funding and it's too big and "vital" to rewrite, so they're stuck with it (probably for another 30+ years, just like they were stuck with the COBOL system it replaced)
It was around that time I started looking (and am still looking...) for a new job.
It's easy to refactor (or completely rewrite) for whatever the hot new fad is when you're dealing with small codebases (<100k loc) that haven't been around very long and most likely won't continue to be in use for long. That's not productive when you're working on a product that has millions of lines of code and has been in use for years (and most likely will continue to be so).
It has nothing to do with "pointy haired bosses" - believe it or not a lot of us [enterprise developers] care more about actually getting stuff done then bragging to our friends how we're playing with whatever is hip this week.