4 ms·

I really dislike these kind of stories. A programmer that is not understood by management. First, they are anecdotal. Second, why are the programmers not takin

by noss 17y ago

I really dislike these kind of stories. A programmer that is not understood by management. First, they are anecdotal. Second, why are the programmers not taking control of management positions if they know so much better? I sure would like to get to play computer games at work, design software from scratch, always end up with clear and short code, make software with usability that users love, and be showered with money. But realistically, I think Alan created the best product for the company. He analysed what was needed, to avoid the risk of creating the wrong software. He got several programmers into the project so the bus-number was higher. He set up facilities for reporting bugs. He started testing early. Now imagine how good Charles would be if he could learn to cooperate and participate in a group like Alan's. Once the software has been written he could leave the maintenance to the others and move on to something more interesting than maintaining accounting software.

cracki 17y ago
you're joking, right? Charles did analysis too, but up-front, and apparently better than Alan.
sofal 17y ago
First, they are anecdotal. There is no inherent evil in anecdotes. This is obviously fiction and was not intended to be used as evidence. If it were, then you would have a reasonable complaint. The purpose of a little story like this is (from Wikipedia): "to reveal a truth more general than the brief tale itself, or to delineate a character trait or the workings of an institution in such a light that it strikes in a flash of insight to their very essence." Second, why are the programmers not taking control of management positions if they know so much better? I see this asked a lot and I don't understand why. First of all, the traits (not skills, but traits) or interests needed for taking control of management positions are different (vastly different depending on the company) than the traits/interests needed to be a good developer. Second, don't forget that our fictional hero Charles eventually quit the company and presumably found a better place. Finding a place that fits you more is sometimes better than trying to change yourself to fit the management mold in a particular company. I think Alan created the best product for the company. Did you read the same story I did, or are you rewriting it into your own parable? Now imagine how good Charles would be if he could learn to cooperate and participate in a group like Alan's. That would be good I think. Let's also imagine how good Alan could be if he could learn to see past the inflated corporate policies, procedures, and checklists and focus on the crux of the problem.
- motoko 17y ago
  Let's also imagine many Alans (corporate engineers) and Charles (hackers) and from this bigger sample, measure how consistently each approach produces an acceptable outcome. It may be that the Charles, on average, produce better solutions with less resources than the Alans, but that individually, more of the Charles projects fail catastrophically. Now imagine how good Charles would be if he could learn to cooperate and participate in a group like Alan's. Let's also imagine how good Alan could be if he could learn to see past the inflated corporate policies, procedures, and checklists and focus on the crux of the problem. Both excellent, I think. But further, let's imagine an organization that arbitrates the risk of each Charles by simultaniously working many cheap, risky Charles on the same problem and managing the results with an Alan-like process. If the Charles are software startups and the Alan-like process is "the Internet," this could work.
william-newman 17y ago
You write "first, they are anecdotal." Fictional, in fact: "once upon a time..." And you write "second, why are the programmers not taking control of management positions if they know so much better?" That question is outside the scope of the fictional dataset of the original post, but see "Jack and the Beancounter" in http://www.skotos.net/articles/BTH_27.shtml http://www.skotos.net/articles/BTH_27.shtml for a related fictional study. And you write "but realistically, I think Alan created the best product for the company." Perhaps I am just being trolled. But at least this was a good excuse to refer to Jack and the Beancounter!
- rdtsc 17y ago
  There is another level to this anecdote, and that is how HN readers respond to it. It seems that some of them identify with Charles, and some with Alan. Some identify because they are or act like Alan and Charles, or they choose the opposite because they had a bad experience with someone like one of them. In other words, in this case the reader identified with Alan because that best describes how that reader works and acts, and they are just instinctively defending their position, even though, clearly, the parable portrays Charles as the better of the two. (Of course, that could be my bias, as I identify with Charles).
dkarl 17y ago
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.
drawkbox 17y ago
While I agree the bus-number is an important factor. Most products, programs, languages, platforms early on were developed by 1-3 programmers, maybe closer to one. Also, the bus number is usually only applied to programmers whereas product managers, executives, etc all dont' have the same bus number over their head. It is almost like companies hate the fact they have a valuable technologist or programmer and try to consistently offset that. Now of course if the single programmer is not communicating or after the project is done they play complexity games then that is different (only one person can read their code) but usually I see the 1-2 man teams obliterate the 3-7 person teams on a regular basis. Programming is not construction, the number of programmers on a project has little to do with success ever. So the bus-number is quite silly. What about the bus-number for the CEO, or the project manager, or the one person that handles billing etc.

by noss 17y ago

cracki 17y ago

you're joking, right? Charles did analysis too, but up-front, and apparently better than Alan.

sofal 17y ago

First, they are anecdotal. There is no inherent evil in anecdotes. This is obviously fiction and was not intended to be used as evidence. If it were, then you would have a reasonable complaint. The purpose of a little story like this is (from Wikipedia): "to reveal a truth more general than the brief tale itself, or to delineate a character trait or the workings of an institution in such a light that it strikes in a flash of insight to their very essence." Second, why are the programmers not taking control of management positions if they know so much better? I see this asked a lot and I don't understand why. First of all, the traits (not skills, but traits) or interests needed for taking control of management positions are different (vastly different depending on the company) than the traits/interests needed to be a good developer. Second, don't forget that our fictional hero Charles eventually quit the company and presumably found a better place. Finding a place that fits you more is sometimes better than trying to change yourself to fit the management mold in a particular company. I think Alan created the best product for the company. Did you read the same story I did, or are you rewriting it into your own parable? Now imagine how good Charles would be if he could learn to cooperate and participate in a group like Alan's. That would be good I think. Let's also imagine how good Alan could be if he could learn to see past the inflated corporate policies, procedures, and checklists and focus on the crux of the problem.

motoko 17y ago
Let's also imagine many Alans (corporate engineers) and Charles (hackers) and from this bigger sample, measure how consistently each approach produces an acceptable outcome. It may be that the Charles, on average, produce better solutions with less resources than the Alans, but that individually, more of the Charles projects fail catastrophically. Now imagine how good Charles would be if he could learn to cooperate and participate in a group like Alan's. Let's also imagine how good Alan could be if he could learn to see past the inflated corporate policies, procedures, and checklists and focus on the crux of the problem. Both excellent, I think. But further, let's imagine an organization that arbitrates the risk of each Charles by simultaniously working many cheap, risky Charles on the same problem and managing the results with an Alan-like process. If the Charles are software startups and the Alan-like process is "the Internet," this could work.

william-newman 17y ago

You write "first, they are anecdotal." Fictional, in fact: "once upon a time..." And you write "second, why are the programmers not taking control of management positions if they know so much better?" That question is outside the scope of the fictional dataset of the original post, but see "Jack and the Beancounter" in http://www.skotos.net/articles/BTH_27.shtml http://www.skotos.net/articles/BTH_27.shtml for a related fictional study. And you write "but realistically, I think Alan created the best product for the company." Perhaps I am just being trolled. But at least this was a good excuse to refer to Jack and the Beancounter!

rdtsc 17y ago
There is another level to this anecdote, and that is how HN readers respond to it. It seems that some of them identify with Charles, and some with Alan. Some identify because they are or act like Alan and Charles, or they choose the opposite because they had a bad experience with someone like one of them. In other words, in this case the reader identified with Alan because that best describes how that reader works and acts, and they are just instinctively defending their position, even though, clearly, the parable portrays Charles as the better of the two. (Of course, that could be my bias, as I identify with Charles).

dkarl 17y ago

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.

drawkbox 17y ago

While I agree the bus-number is an important factor. Most products, programs, languages, platforms early on were developed by 1-3 programmers, maybe closer to one. Also, the bus number is usually only applied to programmers whereas product managers, executives, etc all dont' have the same bus number over their head. It is almost like companies hate the fact they have a valuable technologist or programmer and try to consistently offset that. Now of course if the single programmer is not communicating or after the project is done they play complexity games then that is different (only one person can read their code) but usually I see the 1-2 man teams obliterate the 3-7 person teams on a regular basis. Programming is not construction, the number of programmers on a project has little to do with success ever. So the bus-number is quite silly. What about the bus-number for the CEO, or the project manager, or the one person that handles billing etc.