I dislike this strongly. It is attempting to demean a group of people without really giving them a fair chance. It exaggerates and vilifies the "enterprise programmer" while lionizing the young-but-inexperienced smart programmer. It's a very common theme here on HN. It's playing into the narrative of the young entrepreneur that can drop out of college and build the next successful start-up. The fact is that most people in that situation will fail the first few times as they gain experience. People who can operate like Alan, though obviously Alan does not deliver results, are very valuable in a company. Systems have a tendency to get more complex and you will need people who have experience dealing with that complexity, managing it, and reducing it.
Let me address the parable a bit more directly.
The parable is very hard for me to relate to because to me it seems like the two characters are cherry picked such that they're vastly different in terms of skills. It looks to me like Charles is either much better than Alan at design or got lucky. I think the only wisdom that can be gleaned from the story is to not over-complicate your design. Charles and Alan both spend time upfront designing their code, but it seems that Charles came up with the better design and saw the simple kernel of the problem. That's the only real difference between the two. Alan saw a problem that needed a lot of work and specs to get right, but Charles saw it was actually a very simple problem.
I would say the lesson is to make sure you understand the problem well enough, but Alan is an experienced guy who still couldn't figure it out, so it must have been a hard problem to know how to work with in the first place. Maybe Alan was working defensively to make sure he had all his bases covered in case the design turned out to be different than he initially anticipated. I can't say.
This is indeed a comment-baity article. It is fiction, those two people didn't really exist and do those things. It gets programmers/developers riled up - because it's so believable.
It is indeed the case that the characters are vastly different in terms of skill, and that is sort of the point. Alan did spend time developing his skills, but it was focused on frameworks and processes, and not effective programming or problem solving. Maybe he just didn't have the right start, didn't know what he didn't know, and just went the wrong way from there. But management, and Alan himself, can't tell the difference.
I think that's the ultimate take-away. Non-programmers and "bad" programmers can't recognize good programming, even if they look at results. Well they can, but it takes a lot of time and luck to come across comparable situations. It seems like an intractable problem. They don't know who to trust; and there doesn't seem to be a way to find out for them, except to be genuinely good at developing software... but how to know which way to go about that?
Let me address the parable a bit more directly.
The parable is very hard for me to relate to because to me it seems like the two characters are cherry picked such that they're vastly different in terms of skills. It looks to me like Charles is either much better than Alan at design or got lucky. I think the only wisdom that can be gleaned from the story is to not over-complicate your design. Charles and Alan both spend time upfront designing their code, but it seems that Charles came up with the better design and saw the simple kernel of the problem. That's the only real difference between the two. Alan saw a problem that needed a lot of work and specs to get right, but Charles saw it was actually a very simple problem.
I would say the lesson is to make sure you understand the problem well enough, but Alan is an experienced guy who still couldn't figure it out, so it must have been a hard problem to know how to work with in the first place. Maybe Alan was working defensively to make sure he had all his bases covered in case the design turned out to be different than he initially anticipated. I can't say.