This was awesome Neil. You are wrong in one thing though: software developers do care about this type of stuff. We are being treated like garbage by management who doesn’t talk to us, but talks over our heads, sets arbitrary deadlines, while we have to figure out if what they want is even possible at all.
I think a lot of what you say is in line with my favourite book on the topic: Peopleware. Thanks for your work, keep it up!
Oh yeah, just one more thing: some of these problems don’t really exist in smaller companies (eg. people not pulling their weight), although they have their own set of problems. I think it makes sense to switch between corporations and smaller companies from time to time.
32:15: “Software developers vary wildly in their capability to produce software.”
Already Frederick Brooks observed it in the 1970s and wrote about it in chapter 3 of his book “The Mythical Man-Month.” He also refers to a study that reports a 10-fold difference in productivity. Personally, I believe that it hasn’t changed much since then. I agree with Neil that quite a few bosses maybe do not know it or do not care about the huge difference. I’ve seen many people on projects who were a burden but weren’t fired. In my experience, one reason is that for many bosses, profitability is not the only concern. However, it normally takes center stage when money is tight, for example, in an economic downturn, and then some people are fired, but ironically, not necessarily the worst performers.
54:45: “The thing about collective ownership that is so tragic is [that] the people at the bottom are rewarded because their lack of contribution […] is masked by the people who are very productive […].”
As I understand it, most advocates of agile methods believe that everybody naturally wants to be productive and can improve. One practical idea appears to be to create a non-threatening environment where everybody has a fair chance to improve and grow. Hiding performance differences can contribute to a safe environment. The hope is that the increased productivity of the bottom-performers justifies the potential losses at the top. I’m not saying I fully believe in this theory, not least because I have worked with people who were just lazy, but it’s my understanding of agile thinking.
01:08:15: “And by the way, that’s one of the side-effects of collective ownership: It’s very easy to say, it’s not my problem.”
I know that very well from experience. I once implemented a business report with a very complex, dynamic layout, and it took days to get it all done right. I felt quite proud of the achievement, and in the following months, I made some cosmetic improvements. One day a colleague was asked by management to make a change. That guy didn’t even bother to talk to me and hardcoded a bit of horrible business logic that affected the layout. Of course, he didn’t even bother to tell me after the fact. Normally, I would have tested the report to make sure it still works in all situations. But because I was really annoyed by the affair, I have never tested it since then. I also never spoke to my colleague about it and have never tried to improve the code. As far as I’m concerned, if that’s how we work together, the horrible code and potential errors in the layout are “not my problem.”
This was awesome Neil. You are wrong in one thing though: software developers do care about this type of stuff. We are being treated like garbage by management who doesn’t talk to us, but talks over our heads, sets arbitrary deadlines, while we have to figure out if what they want is even possible at all.
I think a lot of what you say is in line with my favourite book on the topic: Peopleware. Thanks for your work, keep it up!
Oh yeah, just one more thing: some of these problems don’t really exist in smaller companies (eg. people not pulling their weight), although they have their own set of problems. I think it makes sense to switch between corporations and smaller companies from time to time.
32:15: “Software developers vary wildly in their capability to produce software.”
Already Frederick Brooks observed it in the 1970s and wrote about it in chapter 3 of his book “The Mythical Man-Month.” He also refers to a study that reports a 10-fold difference in productivity. Personally, I believe that it hasn’t changed much since then. I agree with Neil that quite a few bosses maybe do not know it or do not care about the huge difference. I’ve seen many people on projects who were a burden but weren’t fired. In my experience, one reason is that for many bosses, profitability is not the only concern. However, it normally takes center stage when money is tight, for example, in an economic downturn, and then some people are fired, but ironically, not necessarily the worst performers.
54:45: “The thing about collective ownership that is so tragic is [that] the people at the bottom are rewarded because their lack of contribution […] is masked by the people who are very productive […].”
As I understand it, most advocates of agile methods believe that everybody naturally wants to be productive and can improve. One practical idea appears to be to create a non-threatening environment where everybody has a fair chance to improve and grow. Hiding performance differences can contribute to a safe environment. The hope is that the increased productivity of the bottom-performers justifies the potential losses at the top. I’m not saying I fully believe in this theory, not least because I have worked with people who were just lazy, but it’s my understanding of agile thinking.
01:08:15: “And by the way, that’s one of the side-effects of collective ownership: It’s very easy to say, it’s not my problem.”
I know that very well from experience. I once implemented a business report with a very complex, dynamic layout, and it took days to get it all done right. I felt quite proud of the achievement, and in the following months, I made some cosmetic improvements. One day a colleague was asked by management to make a change. That guy didn’t even bother to talk to me and hardcoded a bit of horrible business logic that affected the layout. Of course, he didn’t even bother to tell me after the fact. Normally, I would have tested the report to make sure it still works in all situations. But because I was really annoyed by the affair, I have never tested it since then. I also never spoke to my colleague about it and have never tried to improve the code. As far as I’m concerned, if that’s how we work together, the horrible code and potential errors in the layout are “not my problem.”