The story isn't so much about the right way to solve problems, but about how management perceives competence and accomplishment. Alan did all the right things for implementing and supporting a complex piece of software. Charles accomplished the project requirements with a simple piece of software that didn't need as much support as Alan's software. The end result is far better for Charles's company, but Charles was perceived as less competent than Alan. In brief, the problem is this: management understands that complexity is the enemy, but unfortunately, management tends to judge people only by their ability to manage complexity, and not by their ability to avoid creating gratuitous complexity in the first place. That is the point of the parable.
Someday Charles will encounter a challenge that does require a complex project with sophisticated processes and support. Maybe he will fail -- after all, he hasn't proved his ability to manage such a project. However, suppose you have a project that requires four programmers, a well-documented analysis phase, and infrastructure for ongoing support. Would you really rather assign Alan to the project?
Alan did prove that he could manage a complex project. However, he also proved that he designs software that is much more complex than it needs to be. If he needed four programmers and a bunch of infrastructure to handle what should have been a one-man job, how big a team will he need to handle what should require four programmers? Sixteen is an optimistic answer. The project is likely to fail.
Plus, considering that Alan's solution created unnecessary ongoing costs in terms of training and support, how many projects can you afford to let Alan implement? Even this simple project resulted in ongoing costs in training and maintenance. Imagine if you expected Charles's solution and got Alan's instead. Blammo, there goes your budget. I hope you know where you can make some cuts so you can afford to maintain Alan's software. You talk about Charles leaving the maintenance of his code to other people. What are you talking about? His five hundred lines of simple, well-designed code needs no maintenance and can be enhanced later by any competent programmer.
There are many projects my company has done in the last several years that were simply done right and never touched again. They hide in plain sight, flawless but basically forgotten. That's the kind of code Charles produces. There are also lots of projects that we touch over and over again. That's Alan's code. Those projects have snappy names that everybody knows -- we need good names, because we refer to those projects constantly. Every little change in operating conditions exposes new bugs and requires more tinkering. They're like sores that won't heal. Everyone regrets that when we had the time and money to do those projects right -- like Charles would have -- we instead produced a never-quite-right time suck -- like Alan did. The quality and cost of maintenance of a company's software depends entirely on how much Alan code it has. The more Alan code, the more bugs and the higher the cost. A company can only support so much Alan code on a given budget. A company can support a nearly unlimited amount of Charles code.
Finally, you are unwise to assume that Charles needs to "learn to cooperate and participate in a group like Alan's." Maybe he already knows how. Should he have used more resources and incurred more overhead than he needed just to prove he knows how to manage them? That's the kind of bureaucratic head-count-whoring waste that companies are constantly trying to fight. Frugality should be encouraged, not punished.
Someday Charles will encounter a challenge that does require a complex project with sophisticated processes and support. Maybe he will fail -- after all, he hasn't proved his ability to manage such a project. However, suppose you have a project that requires four programmers, a well-documented analysis phase, and infrastructure for ongoing support. Would you really rather assign Alan to the project?
Alan did prove that he could manage a complex project. However, he also proved that he designs software that is much more complex than it needs to be. If he needed four programmers and a bunch of infrastructure to handle what should have been a one-man job, how big a team will he need to handle what should require four programmers? Sixteen is an optimistic answer. The project is likely to fail.
Plus, considering that Alan's solution created unnecessary ongoing costs in terms of training and support, how many projects can you afford to let Alan implement? Even this simple project resulted in ongoing costs in training and maintenance. Imagine if you expected Charles's solution and got Alan's instead. Blammo, there goes your budget. I hope you know where you can make some cuts so you can afford to maintain Alan's software. You talk about Charles leaving the maintenance of his code to other people. What are you talking about? His five hundred lines of simple, well-designed code needs no maintenance and can be enhanced later by any competent programmer.
There are many projects my company has done in the last several years that were simply done right and never touched again. They hide in plain sight, flawless but basically forgotten. That's the kind of code Charles produces. There are also lots of projects that we touch over and over again. That's Alan's code. Those projects have snappy names that everybody knows -- we need good names, because we refer to those projects constantly. Every little change in operating conditions exposes new bugs and requires more tinkering. They're like sores that won't heal. Everyone regrets that when we had the time and money to do those projects right -- like Charles would have -- we instead produced a never-quite-right time suck -- like Alan did. The quality and cost of maintenance of a company's software depends entirely on how much Alan code it has. The more Alan code, the more bugs and the higher the cost. A company can only support so much Alan code on a given budget. A company can support a nearly unlimited amount of Charles code.
Finally, you are unwise to assume that Charles needs to "learn to cooperate and participate in a group like Alan's." Maybe he already knows how. Should he have used more resources and incurred more overhead than he needed just to prove he knows how to manage them? That's the kind of bureaucratic head-count-whoring waste that companies are constantly trying to fight. Frugality should be encouraged, not punished.