Everyone can come up with parables that make some point of view look good. However, two diametrically opposite extremes are presented, instead of a more realistic situation, making the value of the parable zero and none.
For instance, were the 'enterprise' team to be headed by a capable technical lead that forces his team to produce reasonably readable, reasonably documented, reasonably maintainable and futureproof code, then the situation would already be very different. If we add to that that the inexperienced hacker prodigy would produce working code much faster, but his code would turn out to be brittle when someone else has to take care of it, because he does not yet have experience in interacting with lesser gods via his code, then the match would be even more equal. We may still prefer the hacker, but we would be forced to think about the trade offs involved.
I think that enterprise teams typically follow strict syntactic coding standards and then check off the "maintainable" and "readable" requirement from that alone. Additionally, they generate mountains of bloated Word and PowerPoint documents and then consider that responsibility fulfilled. They end up with an incredibly expensive, over-engineered mega-application that exacerbates rather than solves the intended problem. Don't think that this doesn't happen.
There are only so many things that you can force upon a team of programmers, and overall quality and cohesiveness aren't among them.
My definition of "enterprise developer" comes directly from working in a gigantic financial company as well as an even more gigantic government defense contractor. Would you like some more anecdotes?
No, because an "anecdote", by definition, is not statistically relevant.
"Enterprise teams" are not, inherently, profoundly stupid in their practice of software engineering, and not all "hackers" inherently produce worthwhile, quality code.
This completely fabricated fable of software engineering is a simple straw man argument, and I've flagged it accordingly.
Every life lesson that you learn from experience is just a statistically irrelevant anecdote and results in the refinement of a crude heuristic or generalization mechanism for your limited human brain. Never did this fabricated fable state or even hint that this was the way all enterprise teams and all hackers are like. That, my friend, is the straw man argument coming from you.
If this fable didn't hint at that, what was its point?
That convincing management regardless of your productive output is what matters at the end of the day? Perhaps at some organizations, but it's not a particularly accurate, nuanced world view.
I doubt this story would be conveyed in reverse -- the stereotypical "rockstar hacker" produces vast reams of code that will fail catastrophically, but comes out ahead by, upon 'completion', immediately pushing responsibility for the disastrously buggy code to the "stodgy" enterprise engineers who get called in to maintain the project. The "rockstar" moves on to the next project, where he'll repeat this performance, and the stodgy developers get poor performance reviews.
I actually thought the story hinted at the opposite: that individual programmers who from the outside may look like slackers can produce good, simple code and that process isn't everything.
For instance, were the 'enterprise' team to be headed by a capable technical lead that forces his team to produce reasonably readable, reasonably documented, reasonably maintainable and futureproof code, then the situation would already be very different. If we add to that that the inexperienced hacker prodigy would produce working code much faster, but his code would turn out to be brittle when someone else has to take care of it, because he does not yet have experience in interacting with lesser gods via his code, then the match would be even more equal. We may still prefer the hacker, but we would be forced to think about the trade offs involved.