5 ms·

> Every line of code in your system adds to your maintenance burden, and third-party code adds more to your maintenance burden than well-designed and tested2 co

> Every line of code in your system adds to your maintenance burden, and third-party code adds more to your maintenance burden than well-designed and tested2 code your company builds itself. Every SAAS vendor and framework advocate should have to put this on their product in black letters in a white background. Same typography as “Smoking is addictive…”

mrbungie 4y ago
Yeah, good idea, but company architects should make a similar advice about NIH though. A dependency is a dependency, there may be tradeoffs between using third-party software and developing new in-house code, but using "Invented here" code does not vanish any kind of complexity away, it just manages it differently.
- travisgriggs 4y ago
  Agreed. That’s why I thought the footnote in the quote was brilliant. Guess I should’ve included that part as well: > [2] Ay, there’s the rub. I’m assuming competence. (If your company isn’t competent, well, you know what you need to do.)
  - erik_seaberg 4y ago
    The best third-party code has benefitted from industry-wide testing and fixes no single team could match. People we hire might come in already knowing it. Competence is partly in recognizing that a problem has been solved and is no longer a good use of time, at least until we have a plan to make an improvement so great to support the redundant maintenance forever.
barrkel 4y ago
In a company, code you write yourself is a dead end. You want as little of it as possible. Staff turn over. What was a first party piece of code well understood within the company inevitably turns into a poorly documented piece of code written by a third party no longer employed, and there is no community of users to help out with problems. Write and own code which is fundamental to the business model's value proposition, the code which delivers product market fit. Eliminate other code where possible. Upstream or open source improvements that aren't part of the competitive edge. There are exceptions of course, for trivial functionality whose fully loaded cost of integration and upkeep as a third party is higher than home grown, but it's not a lot. The other alternative is to be such an awesome company that nobody who contributes a lot quits.
- bsaul 4y ago
  Before « move fast and break things », there used to be a thing called « documentation ». It included things like « design documents » and would ensure people were able to quickly understand a piece of code.
  - giraffe_lady 4y ago
    Maybe, maybe there was. In my experience when someone talks about how much better "it" used to be and how low we've all sunk these days, "it" never really was as good as they're saying. But maybe. In any case though I live and work now, when companies who prioritize and support the work of creating and maintaining thorough reliable documentation are rare. So I plan my work for situations I can expect to encounter now, not ones that may have been once.
    - bsaul 4y ago
      documentation is an ongoing process. You document your code before, during, and after you write it. I don't understand how one can maintain a piece of code without it for more than a few months, even as a single person. One always forget things. i also don't understand how one can design a piece of architecture without diagrams and maps and all kind of design documents. They are used both for clarity, as well as to discuss between team members. Then keeping them somewhere is also part of documenting the code.
      - giraffe_lady 4y ago
        It's not that I don't see it this way or don't value those things. It's that companies I work for haven't valued them. Doing this won't positively affect my evaluations, but taking time away from other work to do it well, will negatively affect them. If the company would prefer to pay the long-term cost of having no or poor documentation than to pay me to do it now, that's up to them I guess. I take my own notes and go on with my life.

mrbungie 4y ago

Yeah, good idea, but company architects should make a similar advice about NIH though. A dependency is a dependency, there may be tradeoffs between using third-party software and developing new in-house code, but using "Invented here" code does not vanish any kind of complexity away, it just manages it differently.

travisgriggs 4y ago
Agreed. That’s why I thought the footnote in the quote was brilliant. Guess I should’ve included that part as well: > [2] Ay, there’s the rub. I’m assuming competence. (If your company isn’t competent, well, you know what you need to do.)
- erik_seaberg 4y ago
  The best third-party code has benefitted from industry-wide testing and fixes no single team could match. People we hire might come in already knowing it. Competence is partly in recognizing that a problem has been solved and is no longer a good use of time, at least until we have a plan to make an improvement so great to support the redundant maintenance forever.

barrkel 4y ago

In a company, code you write yourself is a dead end. You want as little of it as possible. Staff turn over. What was a first party piece of code well understood within the company inevitably turns into a poorly documented piece of code written by a third party no longer employed, and there is no community of users to help out with problems. Write and own code which is fundamental to the business model's value proposition, the code which delivers product market fit. Eliminate other code where possible. Upstream or open source improvements that aren't part of the competitive edge. There are exceptions of course, for trivial functionality whose fully loaded cost of integration and upkeep as a third party is higher than home grown, but it's not a lot. The other alternative is to be such an awesome company that nobody who contributes a lot quits.

bsaul 4y ago
Before « move fast and break things », there used to be a thing called « documentation ». It included things like « design documents » and would ensure people were able to quickly understand a piece of code.
- giraffe_lady 4y ago
  Maybe, maybe there was. In my experience when someone talks about how much better "it" used to be and how low we've all sunk these days, "it" never really was as good as they're saying. But maybe. In any case though I live and work now, when companies who prioritize and support the work of creating and maintaining thorough reliable documentation are rare. So I plan my work for situations I can expect to encounter now, not ones that may have been once.
  - bsaul 4y ago
    documentation is an ongoing process. You document your code before, during, and after you write it. I don't understand how one can maintain a piece of code without it for more than a few months, even as a single person. One always forget things. i also don't understand how one can design a piece of architecture without diagrams and maps and all kind of design documents. They are used both for clarity, as well as to discuss between team members. Then keeping them somewhere is also part of documenting the code.
    - giraffe_lady 4y ago
      It's not that I don't see it this way or don't value those things. It's that companies I work for haven't valued them. Doing this won't positively affect my evaluations, but taking time away from other work to do it well, will negatively affect them. If the company would prefer to pay the long-term cost of having no or poor documentation than to pay me to do it now, that's up to them I guess. I take my own notes and go on with my life.