The original author is attempting to make a point about software development. It is tempting to use examples like what you just have, but the problem is you've over-extended the metaphor when you do.
The reason your metaphor doesn't work is actually the same reason the original author is wrong as well. Biology is a science that begins with reverse engineering and a lot of guess work, and the human body has no official documentation or handbook.
When developing a new software system it's extremely important to document the business rules implemented, and to use an organized architecture because the guys who built it will very likely not be the people maintaining or updating it.
The frequency of "Phoenix" projects is often the result of code becoming unmaintainable because of how chaotic the design and architecture has become. Even the best documentation and the best engineers cannot make poorly architected and disorganized code maintainable. This is because as a system's code base grows, if the complexity of the architecture also grows it becomes more difficult to make changes without causing defects. This inevitably results in a point where it's faster to completely re-develop the system from scratch than to maintain it in order to add a new feature or even resolve defects.
I've seen this exact scenario play out in every development project I've ever seen that didn't accept the very easy design principal of using and documenting a set of standard design patterns that follow a clear architectural framework.
Losing some efficiency in code is frequently necessary to make the application maintainable beyond the forseable future. Those last 5 words is where everyone seems to get it wrong. A chaotic design is maintainable for the forseable future, but the guys who will maintain the application for its intended life span are beyond the forseable future. They will likely have to work with insufficient design documentation, and a lack of subject matter expertise. Because of these factors, a design which is insufficiently legible is therefore unmaintainable.
The reason your metaphor doesn't work is actually the same reason the original author is wrong as well. Biology is a science that begins with reverse engineering and a lot of guess work, and the human body has no official documentation or handbook.
When developing a new software system it's extremely important to document the business rules implemented, and to use an organized architecture because the guys who built it will very likely not be the people maintaining or updating it.
The frequency of "Phoenix" projects is often the result of code becoming unmaintainable because of how chaotic the design and architecture has become. Even the best documentation and the best engineers cannot make poorly architected and disorganized code maintainable. This is because as a system's code base grows, if the complexity of the architecture also grows it becomes more difficult to make changes without causing defects. This inevitably results in a point where it's faster to completely re-develop the system from scratch than to maintain it in order to add a new feature or even resolve defects.
I've seen this exact scenario play out in every development project I've ever seen that didn't accept the very easy design principal of using and documenting a set of standard design patterns that follow a clear architectural framework.
Losing some efficiency in code is frequently necessary to make the application maintainable beyond the forseable future. Those last 5 words is where everyone seems to get it wrong. A chaotic design is maintainable for the forseable future, but the guys who will maintain the application for its intended life span are beyond the forseable future. They will likely have to work with insufficient design documentation, and a lack of subject matter expertise. Because of these factors, a design which is insufficiently legible is therefore unmaintainable.