4 ms·

Reminds me of this article by Li Hongyi: https://www.csc.gov.sg/articles/how-to-build-good-software https://www.csc.gov.sg/articles/how-to-build-good-software

by jffhn 6y ago

Reminds me of this article by Li Hongyi: https://www.csc.gov.sg/articles/how-to-build-good-software https://www.csc.gov.sg/articles/how-to-build-good-software Quotes: "The main value in software is not the code produced, but the knowledge accumulated by the people who produced it." "This is why relying on external vendors for your core software development is difficult. You may get a running system and its code, but the invaluable knowledge of how it is built and what design choices were made leaves your organisation."

boltzmann_brain 6y ago
And from the first quote, which I strongly agree with, it follows that when people leave the company after building something together, the organization is losing something invaluable. I am baffled that this is not understood and I have witnessed first hand how great teams that are able to work well together collapse and the company has to rebuild the knowledge, wasting time and money.
- l0b0 6y ago
  I suspect most of the time that's because you can't justify keeping a team idle for even a week between projects if that's what it takes to ready the next project for them to work on. I'd be surprised if most businesses even allowed a day of idleness to get a running start with a well-functioning team.
  - chrisweekly 6y ago
    Spot on. The tragic irony is that giving a good team a breather will usually pay dividends, from a strictly utilitarian ROI perspective.
    - username90 6y ago
      Which is why the concept of 20% time is important. It means that 1 day a week your manager can't tell you what to do, so you can work on whatever you think is most important. You could use that time to work on what your manager wants, and most do, but if you have things that you feel are more important you just go and do them.
  - hnick 6y ago
    I had a friend who worked as a project manager for a major telecom and their policy was to basically furlough her for a few weeks (paid time off) after a major project winds down. She's there if something bad happens, but otherwise it's downtime (and retained experience!) before the next project. It seems like a sensible and healthy policy.
    - karatinversion 6y ago
      Perhaps it is different where you are from, but I would usually understand furlough to mean unpaid time off at the company’s request.
      - hnick 6y ago
        I just meant it in the general sense of the word, as a leave of absence at the company's behest that could be paid or unpaid.
thundergolfer 6y ago
That quote's perspective now seems to me to be correct and fundamental to our industry, but it was basically ignored during my degree and I'd say it's still very much under-appreciated in software engineering.
- minipci1321 6y ago
  I'd guess it looks under-appreciated on the surface, because it is hard to run a business on such a premise. Admitting it "officially" ultimately boils down to retaining by all means the engineers who already acquired the knowledge. Some of those will ask for more benefits, others will play games of power, others still will simply refuse to stay once they stopped learning. (In my industry and geo) businesses chose the opposite -- they slice and dice the knowledge into tiny bins so that a total newcomer can learn up quickly enough. This drives down wages but now requires many more people where a few should suffice. Solution to that? Total subcontracting of sw development. Which is of course a slow death for the business, but a) at least it looks like a business model, b) death is slow enough so that managers have time to move on, c) this has a merit of being implementable. The alternative -- finding people who already know or learn very fast, and then keeping them -- is not for every budget.
  - thundergolfer 6y ago
    > Admitting it "officially" ultimately boils down to retaining by all means the engineers who already acquired the knowledge I mostly agree. Admitting it acknowledges the importance of the humans in the system, and diminishes somewhat the allure of the code they write. It pushes for more focus on learning and sharing, and strengthened the labour power of the human interacting with the engineering system, as they're full acknowledged as inseparable from it.

by jffhn 6y ago

boltzmann_brain 6y ago

And from the first quote, which I strongly agree with, it follows that when people leave the company after building something together, the organization is losing something invaluable. I am baffled that this is not understood and I have witnessed first hand how great teams that are able to work well together collapse and the company has to rebuild the knowledge, wasting time and money.

l0b0 6y ago
I suspect most of the time that's because you can't justify keeping a team idle for even a week between projects if that's what it takes to ready the next project for them to work on. I'd be surprised if most businesses even allowed a day of idleness to get a running start with a well-functioning team.
- chrisweekly 6y ago
  Spot on. The tragic irony is that giving a good team a breather will usually pay dividends, from a strictly utilitarian ROI perspective.
  - username90 6y ago
    Which is why the concept of 20% time is important. It means that 1 day a week your manager can't tell you what to do, so you can work on whatever you think is most important. You could use that time to work on what your manager wants, and most do, but if you have things that you feel are more important you just go and do them.
- hnick 6y ago
  I had a friend who worked as a project manager for a major telecom and their policy was to basically furlough her for a few weeks (paid time off) after a major project winds down. She's there if something bad happens, but otherwise it's downtime (and retained experience!) before the next project. It seems like a sensible and healthy policy.
  - karatinversion 6y ago
    Perhaps it is different where you are from, but I would usually understand furlough to mean unpaid time off at the company’s request.
    - hnick 6y ago
      I just meant it in the general sense of the word, as a leave of absence at the company's behest that could be paid or unpaid.

thundergolfer 6y ago

That quote's perspective now seems to me to be correct and fundamental to our industry, but it was basically ignored during my degree and I'd say it's still very much under-appreciated in software engineering.

minipci1321 6y ago
I'd guess it looks under-appreciated on the surface, because it is hard to run a business on such a premise. Admitting it "officially" ultimately boils down to retaining by all means the engineers who already acquired the knowledge. Some of those will ask for more benefits, others will play games of power, others still will simply refuse to stay once they stopped learning. (In my industry and geo) businesses chose the opposite -- they slice and dice the knowledge into tiny bins so that a total newcomer can learn up quickly enough. This drives down wages but now requires many more people where a few should suffice. Solution to that? Total subcontracting of sw development. Which is of course a slow death for the business, but a) at least it looks like a business model, b) death is slow enough so that managers have time to move on, c) this has a merit of being implementable. The alternative -- finding people who already know or learn very fast, and then keeping them -- is not for every budget.
- thundergolfer 6y ago
  > Admitting it "officially" ultimately boils down to retaining by all means the engineers who already acquired the knowledge I mostly agree. Admitting it acknowledges the importance of the humans in the system, and diminishes somewhat the allure of the code they write. It pushes for more focus on learning and sharing, and strengthened the labour power of the human interacting with the engineering system, as they're full acknowledged as inseparable from it.