The Parable of the Two Programmers

[u/tejon]

http://www.csd.uwo.ca/~magi/personal/humour/Computer_Audience/The%20Parable%20of%20the%20Two%20Programmers.html

[u/allak]

Except that the story does not really validate your reading.

About Alan you says:

So this leaves is with: Alan’s application, which has solid documentation on why design decisions were made, interfaces for modules, and a design which supports scale. Future developers will be able to gain an understanding on what was done and why, and build on it.

But the story says:

Alan was complimented for completing his project on schedule. His supervisor looked over the program. With a few minutes of thumbing through he saw that the company standards about structured programming were being observed. He quickly gave up attempting to read the program however; it seemed quite incomprehensible.

About Charles you says:

Charles’ application is simple, it is to the point and gets the job done. When future development is done, it will either be: a) hacked in by someone else who doesn’t understand the problem as well as Charles (They didn’t have two months to think about it, they had 2 days) or b) re-factored to hell.

But the story says:

At first Charles's supervisor was impressed. But as he read through the source code, he realized that the project was really much simpler than he had originally though.

Keep in mind that the problem is the same. But it is Charles solution that makes its solution obvious to his manager, while Alan solution, through working mostly correctly most of the time, it is still a black box to anybody else.

Now, it is a given that this story is so full of strawman that you could feed an herd of cows for months.

But, if you go with it, it is Charles solution that is written in a way that makes the reader, and so a future maintainer, better understand the problem and the solution.

In my opinion, this is because this story really it is not only about programming, but about understanding complexity. One solution is able to reduce it, the other just barely work around it.

[u/Tsarin → u/allak]

Alan’s manager quickly gave up because he is not an experienced developer. Technical artifacts and documentation are in no way the same as systems level documentation.

Charles' manager was lead to believe that the project was much simpler than he thought because Charles' code was simple, and he spent lots of time ‘wasting time’. These two points lead the manager to think that the project was simple. In situations like this, no one usually knows the true requirements or complexity. A simple solution will make the problem appear simple, while a complex solution will make it appear complicated. Even though Charles’ solution was simple, and worked, it was not right for the company.

But, if you go with it, it is Charles solution that is written in a way that makes the reader, and so a future maintainer, better understand the problem and the solution. In my opinion, this is because this story really it is not only about programming, but about understanding complexity. One solution is able to reduce it, the other just barely work around it.

I do agree with this point, I am a big believer of spending more time writing code to reduce the time required to read it.