6 ms·

I haven't read the book and dunno about PG's definition of spaghetti code, but "we can make all these types of modifications without even looking at the rest of

by nnq 14y ago

I haven't read the book and dunno about PG's definition of spaghetti code, but "we can make all these types of modifications without even looking at the rest of the code" sounds like the opposite of what all people I know call sc. I thought that a necessary property of spaghetti code is that almost everything is connected in a way so you can't make a change by only changing something in one place because everything is connected in weird ways because of the lack of structure, so you need to keep the whole program in your head while working on it. Isn't the whole point of well structured programs to be able to work on them while holding as little of the program in your head as possible, so you can work on part of it and be able to "make all these types of modifications without even looking at the rest of the code"? If you have a program that can "evolve" successfully without the need for anyone to "hold it in its head", then a large team can work on it and you can usually replace a 10x programmer with a swarm of 1x ones, basically a pointy haired boss's wet dream...

michaelochurch 14y ago
If you have a program that can "evolve" successfully without the need for anyone to "hold it in its head", then a large team can work on it and you can usually replace a 10x programmer with a swarm of 1x ones, basically a pointy haired boss's wet dream... Why is that the PHB's wet dream? I mean, by observation I agree with you. That is the case, so I am not challengingyou on that. But what could be the underlying reason, seeing as 10x programmers are only 1.5-3.0x as expensive? It seems like PHBs shoot themselves in the foot, repeatedly, without mercy.
- gnaritas 14y ago
  PHB's tend to measure themselves by how many people they're in charge of; better 10 guys than 1 that's productive as 10. PHB's aren't entrepreneur types, they're middle managers who require underlying to justify their existence, the more the better.
  - michaelochurch 14y ago
    That's been my feeling about it, too. Headcount and control rather than actual productivity. Also, I feel like middle managers have a terrible incentive profile. If an underling really shines, then it reflects well on the underling. If one underperforms or makes a mess, boss gets shat on for not keeping them in line. It's easy to rip on middle managers, but they have a shitty job and it's not their fault. It's just structured badly. I think it's easier to understand why middle managers are the way they are once one understands their incentive structure. They participate in an employee's downside but not upside (she did it herself) so of course they're going to be the way they are. I may be radical but I think open allocation is the only answer for software development. All the nonsensical process that grows up around closed allocation seems archaic and stifling. I think typical middle management is useless. What you really need are HR-independent mentors. Aside from mentoring, the other thing managers can do (firing) should be so rare in a well-run company that you only need one per few hundred people.
    - enupten 14y ago
      .. brought to you by her Majesty's Civil service. http://en.wikipedia.org/wiki/Yes_Minister http://en.wikipedia.org/wiki/Yes_Minister
    - gingerlime 14y ago
      I recommend reading about the Gervais principle![1] [1]http://www.ribbonfarm.com/2009/10/07/the-gervais-principle-or-the-office-according-to-the-office/ http://www.ribbonfarm.com/2009/10/07/the-gervais-principle-o...
      - dpritchett 14y ago
        When Michael read about the Gervais principle it inspired about 100,000 words of response: http://michaelochurch.wordpress.com/?s=gervais&submit=Search http://michaelochurch.wordpress.com/?s=gervais&submit=Se...
        gingerlime 14y ago
- yen223 14y ago
  Risk management. Assuming the PHB can hire 10 junior devs or 1 senior dev at the same cost: If you have 10 junior devs and 1 decides to quit, the PHB can swap him out fairly easily - he just has to wait for graduation day. If you have 1 senior dev and he decides to quit, the PHB's hands are severely tied, especially if the company is located in a place where talent is lacking. This is also the reason why mainstream languages will likely remain popular forever in the enterprise world - no one wants to take a chance on a language that only 5% of devs know.
  - eru 14y ago
    > This is also the reason why mainstream languages will likely remain popular forever in the enterprise world - no one wants to take a chance on a language that only 5% of devs know. Unless they have a legacy system. Or what percentage of developers know Cobol these days?
    - justanotherbody 14y ago
      You've just proven the point. Commit to the popular language because finding maintainers in X years will be that much easier
    - kyllo 14y ago
      They're not taking a chance on a language only 5% of devs know, precisely because they know how painful it is to be chained to a legacy system. So they do every new project in the industry standard language, which is Java. Problem is, the industry standard used to be COBOL. Sooner or later, if/when Java falls out of vogue and stops evolving, they will end up with two legacy systems instead of just one.
    - dagw 14y ago
      I can't find the link right now, but I saw an ad from a technical school here in Sweden only a couple of weeks ago advertising their new 1 year Cobol developer program.
      - yen223 14y ago
- rizzom5000 14y ago
  But what could be the underlying reason, seeing as 10x programmers are only 1.5-3.0x as expensive? I'd venture that it's because something like less than x% of all programmers are elite; where x is some number between 5 and 10. In this case, if you are PHB and have a budget of y for staff (where y <= average) and time variable of z (where z <= average) for a release date - it would appear that you are an incompetent PHB if you believe you can hire an elite programmer to solve your problem(s).
- nnq 14y ago
  I think people are not as rational as they seem and it's basically a form of power hunger - PHBs feel more powerful when the distance between them and their employees is larger: one feels much more powerful having 10 people well below him than having 1 person a little below him, and 10x programmers that also have social skills in a company where IT matters will have a say in lots of things, even not IT related and even if not in a direct way, so they end up closer to the PHB on the power scale than each of the 10 1x ones, which is a bad feeling... Now if the 10x is totally lacking in social skills and introvert, that's ok for the PHB, but if lacking in social skills and more of an extrovert, it's bad again, because although he wouldn't have a say in things because he's "the smart asshole", he'll make everyone, including the PHB, feel and look stupid (and they probably will be 20 iq point below him and they'll know it and feel somewhat demoralized by him). Basically the 10x guy is uncomfortable for all guys above him (not only in software but in any other field that has a 10x skill gradient) that lack self-control, self-knowledge and people skills (what's called "being wise"), and most PHBs are "very not wise".
- yummyfajitas 14y ago
  Why is that the PHB's wet dream? Because it makes the business more failure tolerant. Finding even one 10x guy is tough - many teams will have only 1 or 2 of them, and a swarm of 1x guys. If the 10x guy is on vacation, quits, or has something more important to do, you can throw one of the 1x guys at it. You don't need nefarious "I hate the 10x cause I'm a psychopathic PHB" motives to explain this one.
laureny 14y ago
> I haven't read the book and dunno about PG's definition of spaghetti code, but "we can make all these types of modifications without even looking at the rest of the code" sounds like the opposite of what all people I know call sc. That was exactly my thought as well, I had to reread the part twice to make sure. This is the definition of maintainable (or maybe even well-designed) code when all its parts are carefully isolated.
- hmbg 14y ago
  I think the point is that writing code on isolated parts without thinking about the overall purpose and architecture of the program leads to bloat, repeated functionality and diverging paradigms/conventions in the same codebase. I agree that's not the traditional definition of spaghetti code, but it's a problem in many large software projects. Adding that together, well designed code is the foundation of really bad code. That could explain a lot.
brudgers 14y ago
The quotation is nearly twenty years old. For context that's before Java [practically speaking] and before C++ was standardized - and when programmers of Graham's age had a background using PEEK and POKE and GOTO in BASIC or exposure to assembly and the older programmers had often seen plugboards in use. I won't guess at Graham's definition today. He can speak for himself, anyway. But it resonated with me in the context of Rich Hickey's ideas - particularly "Are We There Yet?" http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hic... As I understand it, an issue with [some] object systems is that when objects are made by aggregation, rather than inheritance, they are of a different type than each of their components. And this requires the programmer to write some code [however minimal] for the new type in order to reimplement any desirable feature of the objects from which it is composed. In other words, the behavior of an aggregate of objects is undefined. Hickey's comparison is to data. Which he claims aggregates into more data. When, I ask myself "what is data?" lisp-a-cadabra - it's code. Which is the [structuralist] way in which I read Graham's note.
flyinRyan 14y ago
You're absolutely right. This is what is meant by spaghetti code; everything is connected and you can't tell what is connected to what until you start pulling things out. I've only worked on one or two code bases that were truly spaghetti code and I replaced them both completely in short order.

by nnq 14y ago

michaelochurch 14y ago

If you have a program that can "evolve" successfully without the need for anyone to "hold it in its head", then a large team can work on it and you can usually replace a 10x programmer with a swarm of 1x ones, basically a pointy haired boss's wet dream... Why is that the PHB's wet dream? I mean, by observation I agree with you. That is the case, so I am not challengingyou on that. But what could be the underlying reason, seeing as 10x programmers are only 1.5-3.0x as expensive? It seems like PHBs shoot themselves in the foot, repeatedly, without mercy.

gnaritas 14y ago
PHB's tend to measure themselves by how many people they're in charge of; better 10 guys than 1 that's productive as 10. PHB's aren't entrepreneur types, they're middle managers who require underlying to justify their existence, the more the better.
- michaelochurch 14y ago
  That's been my feeling about it, too. Headcount and control rather than actual productivity. Also, I feel like middle managers have a terrible incentive profile. If an underling really shines, then it reflects well on the underling. If one underperforms or makes a mess, boss gets shat on for not keeping them in line. It's easy to rip on middle managers, but they have a shitty job and it's not their fault. It's just structured badly. I think it's easier to understand why middle managers are the way they are once one understands their incentive structure. They participate in an employee's downside but not upside (she did it herself) so of course they're going to be the way they are. I may be radical but I think open allocation is the only answer for software development. All the nonsensical process that grows up around closed allocation seems archaic and stifling. I think typical middle management is useless. What you really need are HR-independent mentors. Aside from mentoring, the other thing managers can do (firing) should be so rare in a well-run company that you only need one per few hundred people.
  - enupten 14y ago
    .. brought to you by her Majesty's Civil service. http://en.wikipedia.org/wiki/Yes_Minister http://en.wikipedia.org/wiki/Yes_Minister
  - gingerlime 14y ago
    I recommend reading about the Gervais principle![1] [1]http://www.ribbonfarm.com/2009/10/07/the-gervais-principle-or-the-office-according-to-the-office/ http://www.ribbonfarm.com/2009/10/07/the-gervais-principle-o...
    - dpritchett 14y ago
      When Michael read about the Gervais principle it inspired about 100,000 words of response: http://michaelochurch.wordpress.com/?s=gervais&submit=Search http://michaelochurch.wordpress.com/?s=gervais&submit=Se...
      - gingerlime 14y ago
yen223 14y ago
Risk management. Assuming the PHB can hire 10 junior devs or 1 senior dev at the same cost: If you have 10 junior devs and 1 decides to quit, the PHB can swap him out fairly easily - he just has to wait for graduation day. If you have 1 senior dev and he decides to quit, the PHB's hands are severely tied, especially if the company is located in a place where talent is lacking. This is also the reason why mainstream languages will likely remain popular forever in the enterprise world - no one wants to take a chance on a language that only 5% of devs know.
- eru 14y ago
  > This is also the reason why mainstream languages will likely remain popular forever in the enterprise world - no one wants to take a chance on a language that only 5% of devs know. Unless they have a legacy system. Or what percentage of developers know Cobol these days?
  - justanotherbody 14y ago
    You've just proven the point. Commit to the popular language because finding maintainers in X years will be that much easier
  - kyllo 14y ago
    They're not taking a chance on a language only 5% of devs know, precisely because they know how painful it is to be chained to a legacy system. So they do every new project in the industry standard language, which is Java. Problem is, the industry standard used to be COBOL. Sooner or later, if/when Java falls out of vogue and stops evolving, they will end up with two legacy systems instead of just one.
  - dagw 14y ago
    I can't find the link right now, but I saw an ad from a technical school here in Sweden only a couple of weeks ago advertising their new 1 year Cobol developer program.
    - yen223 14y ago
rizzom5000 14y ago
But what could be the underlying reason, seeing as 10x programmers are only 1.5-3.0x as expensive? I'd venture that it's because something like less than x% of all programmers are elite; where x is some number between 5 and 10. In this case, if you are PHB and have a budget of y for staff (where y <= average) and time variable of z (where z <= average) for a release date - it would appear that you are an incompetent PHB if you believe you can hire an elite programmer to solve your problem(s).
nnq 14y ago
I think people are not as rational as they seem and it's basically a form of power hunger - PHBs feel more powerful when the distance between them and their employees is larger: one feels much more powerful having 10 people well below him than having 1 person a little below him, and 10x programmers that also have social skills in a company where IT matters will have a say in lots of things, even not IT related and even if not in a direct way, so they end up closer to the PHB on the power scale than each of the 10 1x ones, which is a bad feeling... Now if the 10x is totally lacking in social skills and introvert, that's ok for the PHB, but if lacking in social skills and more of an extrovert, it's bad again, because although he wouldn't have a say in things because he's "the smart asshole", he'll make everyone, including the PHB, feel and look stupid (and they probably will be 20 iq point below him and they'll know it and feel somewhat demoralized by him). Basically the 10x guy is uncomfortable for all guys above him (not only in software but in any other field that has a 10x skill gradient) that lack self-control, self-knowledge and people skills (what's called "being wise"), and most PHBs are "very not wise".
yummyfajitas 14y ago
Why is that the PHB's wet dream? Because it makes the business more failure tolerant. Finding even one 10x guy is tough - many teams will have only 1 or 2 of them, and a swarm of 1x guys. If the 10x guy is on vacation, quits, or has something more important to do, you can throw one of the 1x guys at it. You don't need nefarious "I hate the 10x cause I'm a psychopathic PHB" motives to explain this one.

laureny 14y ago

> I haven't read the book and dunno about PG's definition of spaghetti code, but "we can make all these types of modifications without even looking at the rest of the code" sounds like the opposite of what all people I know call sc. That was exactly my thought as well, I had to reread the part twice to make sure. This is the definition of maintainable (or maybe even well-designed) code when all its parts are carefully isolated.

hmbg 14y ago
I think the point is that writing code on isolated parts without thinking about the overall purpose and architecture of the program leads to bloat, repeated functionality and diverging paradigms/conventions in the same codebase. I agree that's not the traditional definition of spaghetti code, but it's a problem in many large software projects. Adding that together, well designed code is the foundation of really bad code. That could explain a lot.

brudgers 14y ago

The quotation is nearly twenty years old. For context that's before Java [practically speaking] and before C++ was standardized - and when programmers of Graham's age had a background using PEEK and POKE and GOTO in BASIC or exposure to assembly and the older programmers had often seen plugboards in use. I won't guess at Graham's definition today. He can speak for himself, anyway. But it resonated with me in the context of Rich Hickey's ideas - particularly "Are We There Yet?" http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hic... As I understand it, an issue with [some] object systems is that when objects are made by aggregation, rather than inheritance, they are of a different type than each of their components. And this requires the programmer to write some code [however minimal] for the new type in order to reimplement any desirable feature of the objects from which it is composed. In other words, the behavior of an aggregate of objects is undefined. Hickey's comparison is to data. Which he claims aggregates into more data. When, I ask myself "what is data?" lisp-a-cadabra - it's code. Which is the [structuralist] way in which I read Graham's note.

flyinRyan 14y ago

You're absolutely right. This is what is meant by spaghetti code; everything is connected and you can't tell what is connected to what until you start pulling things out. I've only worked on one or two code bases that were truly spaghetti code and I replaced them both completely in short order.