Actually, in most cases - no, they can't. Or, rather, they can't figure it out as fast as they're "needed" to.
> if there's a real need with no alternative
What happens instead is that somebody with no real knowledge of software development says, "we need this change made in two weeks. We need this." That this might be impossible for any human being, living or dead, is completely ignored. If the programmer this is dumped on even suggests making any clarifying improvements to the code, even that is rejected because "we need" this.
And two weeks come and go, something was changed because there was a deadline, but the something that was changed broke a dozen other things nobody even remembers were there, and now there are bugs waiting to be discovered by unsuspecting users.
> it's a matter of incentives and prioritization
I know what you mean - it is, technically possible but it's never feasible because it's not predictable.
When you run up against this wall, it is often easier to write new software than to maintain the legacy code. Long term you are duplicating a ton of work at huge expense, but that is frequently the fate of successful projects: to be replaced with something sub-optimal that is nonetheless more tractable because there is less of it at the beginning and rapid feature development makes it easy to demonstrate value.
More often I've seen that all that fast development time is spent trying to replicate features of the old system that were missed or deferred when designing the new system. Strangely, when they have achieved feature parity, the new system often doesn't seem so easy to work with.
Loyalty gets you very little in today's climate. Why should I spend time understanding the current system that was developed on yesterdays hotness?
I need to spend my time here developing on the latest trends on a new solution (learning more from running into the same walls the current system did) - not learning the domain knowledge + old framework, so I can move on after a year and earn more at the next place.
Is this good for the world? No. But unless you want to swing the hammock and work at institions that value incumbents, the incentive is to do whatever work improves your resume, not what benefits the company.
I don't personally like it, and I often see old systems that are just fine get thrown out and replaced with the a less featured replacement that grow into the same kludge as the first, but I can't ignore that when you do that you learn way more and have better examples to point at in interviews.
Actually, in most cases - no, they can't. Or, rather, they can't figure it out as fast as they're "needed" to.
> if there's a real need with no alternative
What happens instead is that somebody with no real knowledge of software development says, "we need this change made in two weeks. We need this." That this might be impossible for any human being, living or dead, is completely ignored. If the programmer this is dumped on even suggests making any clarifying improvements to the code, even that is rejected because "we need" this.
And two weeks come and go, something was changed because there was a deadline, but the something that was changed broke a dozen other things nobody even remembers were there, and now there are bugs waiting to be discovered by unsuspecting users.
> it's a matter of incentives and prioritization
I know what you mean - it is, technically possible but it's never feasible because it's not predictable.