4 ms·

I think us developer overstate how important we think this is. Unless time to market is a consideration then they will probably just accept throwing people at i

I think us developer overstate how important we think this is. Unless time to market is a consideration then they will probably just accept throwing people at it and then get some poor souls to clean up afterwards.

kqr 7y ago
That probably costs more, though. Software engineering is mainly knowledge work. This means the majority of work consists not of building stuff, but acquiring and organising knowledge. I've read somewhere that about 50% of the job is gathering information. When a person leaves after having spent two years at a company, it might look like you get to keep everything they've been working on, but this is far from true. If the 50% assumption is correct, a person leaving after two years means you throw a full year of work into the dump. This is a huge cost, but it's hidden.
- uk_programmer 7y ago
  This is exactly what I am talking about. You are overestimating how important it is. The code is there and (presumably) in source control. It really isn't that difficult for someone to get the source, compile it and fire up the debugger and carry on where the previous person left off.
  - Xylakant 7y ago
    I’ve seen very few projects of more than moderate complexity where “check out code and compile it” is the complex part. Who’s consuming the code? Who are the stakeholders? How does this component integrate into the full picture of the application? How do I need to talk to that person that I really need to change something?
    - uk_programmer 7y ago
      I think you are missing the overall point that you are overestimating how important knowing that is.
  - kqr 7y ago
    And I'm saying that if you have only, or mainly, worked at projects where all information (including about failed historical approaches and why they failed) is encoded in the source code, you have been very lucky to the point where I have a hard time imagining that to be true. There is so much implicit knowledge that goes into the finals source artifact that is not spelled out.
    - uk_programmer 7y ago
      Sure Domain Knowledge is important. But again this can all be discovered as you go along. I had an interview at a this week for my next contract where they made redundant most of their employees as the business decided to just go with turnkey applications. They will get someone like me in for 3 to 6 months to do application maintenance on anything they can't replace. This will be stuff like implementing stuff from penetration-testing, upgrading the applications and documenting missing bits and pieces and letting the business know what needs doing and where. I don't need a pension being paid, no HR overhead (they can just ask me to leave whenever pretty much). I will be able to gleen enough from the business and their IT to piece the bits together. This is literally my bread and butter.
      - fsloth 7y ago
        "But again this can all be discovered as you go along." How are you going to discover that from just the sources without any institutional knowledge? It sounds to me this applies only to a specific niche you've managed to find. I.e. you get only those gigs where institutional knowledge is not paramount as the employers who need deep domain knowledge are not even trying to hire you. I don't mean this in a deragoratory sense - it sounds to me you provide great value to your employers - but just in that you work in a specific market segment and what is true in your segment might not hold in others.
        uk_programmer 7y ago
        The business stake holders are going to be there. Sure at some point it might be just too much work but typically there is somewhere in between where you can piece it together. > I don't mean this in a deragoratory sense - it sounds to me you provide great value to your employers - but just in that you work in a specific market segment and what is true in your segment might not hold in others. I've worked in many different sectors. Normally fintech though.
  - fsloth 7y ago
    I'm sure there are lots of production codebases like that. But there are lots of codebases that actually require the institutional knowledge to use and modify - for example a decades old CAD application. So your example is not a universal rule.
    - uk_programmer 7y ago
      I find it incredibly frustrating and tbh it saddens me when I say a generality in this case being "developers overestimate their worth to the business" and people chime in with all the exceptions that they think disproves it. Obviously there are exceptions to the rule. However unless building the tech is the business you are seen just as a cost to the business in most circumstances.

kqr 7y ago

That probably costs more, though. Software engineering is mainly knowledge work. This means the majority of work consists not of building stuff, but acquiring and organising knowledge. I've read somewhere that about 50% of the job is gathering information. When a person leaves after having spent two years at a company, it might look like you get to keep everything they've been working on, but this is far from true. If the 50% assumption is correct, a person leaving after two years means you throw a full year of work into the dump. This is a huge cost, but it's hidden.

uk_programmer 7y ago
This is exactly what I am talking about. You are overestimating how important it is. The code is there and (presumably) in source control. It really isn't that difficult for someone to get the source, compile it and fire up the debugger and carry on where the previous person left off.
- Xylakant 7y ago
  I’ve seen very few projects of more than moderate complexity where “check out code and compile it” is the complex part. Who’s consuming the code? Who are the stakeholders? How does this component integrate into the full picture of the application? How do I need to talk to that person that I really need to change something?
  - uk_programmer 7y ago
    I think you are missing the overall point that you are overestimating how important knowing that is.
- kqr 7y ago
  And I'm saying that if you have only, or mainly, worked at projects where all information (including about failed historical approaches and why they failed) is encoded in the source code, you have been very lucky to the point where I have a hard time imagining that to be true. There is so much implicit knowledge that goes into the finals source artifact that is not spelled out.
  - uk_programmer 7y ago
    Sure Domain Knowledge is important. But again this can all be discovered as you go along. I had an interview at a this week for my next contract where they made redundant most of their employees as the business decided to just go with turnkey applications. They will get someone like me in for 3 to 6 months to do application maintenance on anything they can't replace. This will be stuff like implementing stuff from penetration-testing, upgrading the applications and documenting missing bits and pieces and letting the business know what needs doing and where. I don't need a pension being paid, no HR overhead (they can just ask me to leave whenever pretty much). I will be able to gleen enough from the business and their IT to piece the bits together. This is literally my bread and butter.
    - fsloth 7y ago
      "But again this can all be discovered as you go along." How are you going to discover that from just the sources without any institutional knowledge? It sounds to me this applies only to a specific niche you've managed to find. I.e. you get only those gigs where institutional knowledge is not paramount as the employers who need deep domain knowledge are not even trying to hire you. I don't mean this in a deragoratory sense - it sounds to me you provide great value to your employers - but just in that you work in a specific market segment and what is true in your segment might not hold in others.
      - uk_programmer 7y ago
        The business stake holders are going to be there. Sure at some point it might be just too much work but typically there is somewhere in between where you can piece it together. > I don't mean this in a deragoratory sense - it sounds to me you provide great value to your employers - but just in that you work in a specific market segment and what is true in your segment might not hold in others. I've worked in many different sectors. Normally fintech though.
- fsloth 7y ago
  I'm sure there are lots of production codebases like that. But there are lots of codebases that actually require the institutional knowledge to use and modify - for example a decades old CAD application. So your example is not a universal rule.
  - uk_programmer 7y ago
    I find it incredibly frustrating and tbh it saddens me when I say a generality in this case being "developers overestimate their worth to the business" and people chime in with all the exceptions that they think disproves it. Obviously there are exceptions to the rule. However unless building the tech is the business you are seen just as a cost to the business in most circumstances.