4 ms·

I disagree. It should be only cleaned up, if nothing else is more important.

apalmer 4y ago
I think there is a minimum floor that should be allocated to this kind of work. It doesn’t make sense to clean everything to a perfect condition but there should be some amount of ‘keep your room clean’ level of hygiene that’s maintained
- Archelaos 4y ago
  I think "cleaning up x" should just be handled as any other to-do-list item. That means evaluating its cost and benefits in context with the other items on the list. Then do what is on position one, then on position two, then on position three, ... Re-evaluate the list from time to time.
  - wpietri 4y ago
    Fine in theory, but often bad in practice, because in a lot of places prioritization is done by people with little or no technical background and lots of incentive to show progress. There are a lot of ways to do this, but my general preference is a black budget plus explicit "credit card" usage. E.g., the team has high standards for any new feature work and quietly spends 15% of their time every week on continuous technical improvement. If the product manager wants to break the normal standards and take on technical debt (e.g., rush have feature X ready for trade show), then you break the work into "rush to add feature X" and "clean up feature X mess". The first gets done before the trade show, the second after. And personally, if a product manager doesn't honor the deal, I say they get their credit card taken away for a while, because they've proven they can't be trusted to do right by the team and the company.
    - Archelaos 4y ago
      Actually, I have an explicit agreement that I can spent around 10% of my time on issues of my choice, without having to check with the management. And sometimes, for bigger refactoring work, I have negotiated explicit to-do-list items. On the other side, in the process of re-evaluating the to-dos, I myself often recommend to postpone refactoring when I see the need for implementing a certain feature fast or when I have the impression that the code quality is "good enough" for the moment. Since management trusts me that I can appreciate the business perspective as well, I actually have little trouble asserting myself when I think a particular refactoring issue should be prioritized. So in my case, it works in practice.
      - wpietri 4y ago
        No, treating as "any other to-do list item" does not work fine in practice. And you know it, because you spend 10% of your time on work specifically kept out of the normal to-do list flow. And I'm glad you have a very good relationship with your business stakeholders, but please recognize that's not the modal case, and that giving advice as if it were is going to be bad for people with other circumstances.
- wpietri 4y ago
  Exactly. Professional kitchens are very busy, time-sensitive places. But most of the good ones work pretty clean. Not because they're aesthetically fussy, but because they understand that being pretty fast requires being pretty clean. There's a bit from Bourdain's Kitchen Confidential that really resonates with me along these lines: Mise-en-place is the religion of all good line cooks. Do not fuck with a line cook’s ‘meez’ — meaning his setup, his carefully arranged supplies of sea salt, rough-cracked pepper, softened butter, cooking oil, wine, backups, and so on. As a cook, your station, and its condition, its state of readiness, is an extension of your nervous system... The universe is in order when your station is set up the way you like it: you know where to find everything with your eyes closed, everything you need during the course of the shift is at the ready at arm’s reach, your defenses are deployed. If you let your mise-en-place run down, get dirty and disorganized, you’ll quickly find yourself spinning in place and calling for backup. I worked with a chef who used to step behind the line to a dirty cook’s station in the middle of a rush to explain why the offending cook was falling behind. He’d press his palm down on the cutting board, which was littered with peppercorns, spattered sauce, bits of parsley, bread crumbs and the usual flotsam and jetsam that accumulates quickly on a station if not constantly wiped away with a moist side towel. “You see this?” he’d inquire, raising his palm so that the cook could see the bits of dirt and scraps sticking to his chef’s palm. “That’s what the inside of your head looks like now.” Having a reasonably tidy codebase that the whole team understands well is very much like that for me.
  - kl4m 4y ago
    Also discussed at length in the book Work Clean by Dan Charnas
wpietri 4y ago
On the one hand, that's trivially true and I agree. In which case, I'm saying that keeping debt low is pretty important. On the other, it's a statement that executive priorities mostly trump technical priorities, which I deeply disagree with. Executives generally have a poor understanding of how technical debt works over the long term: https://web.archive.org/web/20190709091156/http://agilefocus.com:80/2009/06/22/the-3-kinds-of-code/ https://web.archive.org/web/20190709091156/http://agilefocus... Week to week, many will say, "OMG, this feature is way more important than technical debt". But year to year, they will say, "Why is it so hard to get anything done here?!? Why is our stuff so buggy?!? We must have terrible developers!" Which is both a management failure and a failure of developers to maintain professional standards. The first is mostly out of our control, but the second is up to us.
- Archelaos 4y ago
  I just do not think that there is anything magic about what some people call "technical debt" (but I prefer to call a "code smell", since how debt works fundamtentally is quite different from people's typical conclusions around "technical debt"). Eliminating a particular code smell is like any other improvement to an application, but with a special focus on its lifecycle and the associated costs and benefits. And there are opportunity costs: Fixing a particular code smell means that future features of the application will get delayed. And the question is not only at what point in the future, in some (YAGNI) cases perhaps never, our now improved code quality let us catch up with otherwise earlier feature implementations: The extended time-to-market for our new features also comes at a price. So to decide what is actually best, it is not enough to look only at the technical side of a software project. The time-to-market (or time-to-use) cost, which has nothing to do with engineering per se, must also be taken into account. When deciding when a particular code smell should be fixed, both technical and business aspects are important: Technical effort and benefit must be evaluated and weighed against the aforementioned opportunity costs of feature delays. That is why good cooperation and open communication between engineers and business people within a company is important. If this is not the case, well, this is another smell that perhaps needs to be refactored first. If it is worthwhile ...
  - 4y ago

I think there is a minimum floor that should be allocated to this kind of work. It doesn’t make sense to clean everything to a perfect condition but there should be some amount of ‘keep your room clean’ level of hygiene that’s maintained

Archelaos 4y ago
I think "cleaning up x" should just be handled as any other to-do-list item. That means evaluating its cost and benefits in context with the other items on the list. Then do what is on position one, then on position two, then on position three, ... Re-evaluate the list from time to time.
- wpietri 4y ago
  Fine in theory, but often bad in practice, because in a lot of places prioritization is done by people with little or no technical background and lots of incentive to show progress. There are a lot of ways to do this, but my general preference is a black budget plus explicit "credit card" usage. E.g., the team has high standards for any new feature work and quietly spends 15% of their time every week on continuous technical improvement. If the product manager wants to break the normal standards and take on technical debt (e.g., rush have feature X ready for trade show), then you break the work into "rush to add feature X" and "clean up feature X mess". The first gets done before the trade show, the second after. And personally, if a product manager doesn't honor the deal, I say they get their credit card taken away for a while, because they've proven they can't be trusted to do right by the team and the company.
  - Archelaos 4y ago
    Actually, I have an explicit agreement that I can spent around 10% of my time on issues of my choice, without having to check with the management. And sometimes, for bigger refactoring work, I have negotiated explicit to-do-list items. On the other side, in the process of re-evaluating the to-dos, I myself often recommend to postpone refactoring when I see the need for implementing a certain feature fast or when I have the impression that the code quality is "good enough" for the moment. Since management trusts me that I can appreciate the business perspective as well, I actually have little trouble asserting myself when I think a particular refactoring issue should be prioritized. So in my case, it works in practice.
    - wpietri 4y ago
      No, treating as "any other to-do list item" does not work fine in practice. And you know it, because you spend 10% of your time on work specifically kept out of the normal to-do list flow. And I'm glad you have a very good relationship with your business stakeholders, but please recognize that's not the modal case, and that giving advice as if it were is going to be bad for people with other circumstances.
wpietri 4y ago
Exactly. Professional kitchens are very busy, time-sensitive places. But most of the good ones work pretty clean. Not because they're aesthetically fussy, but because they understand that being pretty fast requires being pretty clean. There's a bit from Bourdain's Kitchen Confidential that really resonates with me along these lines: Mise-en-place is the religion of all good line cooks. Do not fuck with a line cook’s ‘meez’ — meaning his setup, his carefully arranged supplies of sea salt, rough-cracked pepper, softened butter, cooking oil, wine, backups, and so on. As a cook, your station, and its condition, its state of readiness, is an extension of your nervous system... The universe is in order when your station is set up the way you like it: you know where to find everything with your eyes closed, everything you need during the course of the shift is at the ready at arm’s reach, your defenses are deployed. If you let your mise-en-place run down, get dirty and disorganized, you’ll quickly find yourself spinning in place and calling for backup. I worked with a chef who used to step behind the line to a dirty cook’s station in the middle of a rush to explain why the offending cook was falling behind. He’d press his palm down on the cutting board, which was littered with peppercorns, spattered sauce, bits of parsley, bread crumbs and the usual flotsam and jetsam that accumulates quickly on a station if not constantly wiped away with a moist side towel. “You see this?” he’d inquire, raising his palm so that the cook could see the bits of dirt and scraps sticking to his chef’s palm. “That’s what the inside of your head looks like now.” Having a reasonably tidy codebase that the whole team understands well is very much like that for me.
- kl4m 4y ago
  Also discussed at length in the book Work Clean by Dan Charnas

wpietri 4y ago

On the one hand, that's trivially true and I agree. In which case, I'm saying that keeping debt low is pretty important. On the other, it's a statement that executive priorities mostly trump technical priorities, which I deeply disagree with. Executives generally have a poor understanding of how technical debt works over the long term: https://web.archive.org/web/20190709091156/http://agilefocus.com:80/2009/06/22/the-3-kinds-of-code/ https://web.archive.org/web/20190709091156/http://agilefocus... Week to week, many will say, "OMG, this feature is way more important than technical debt". But year to year, they will say, "Why is it so hard to get anything done here?!? Why is our stuff so buggy?!? We must have terrible developers!" Which is both a management failure and a failure of developers to maintain professional standards. The first is mostly out of our control, but the second is up to us.

Archelaos 4y ago
I just do not think that there is anything magic about what some people call "technical debt" (but I prefer to call a "code smell", since how debt works fundamtentally is quite different from people's typical conclusions around "technical debt"). Eliminating a particular code smell is like any other improvement to an application, but with a special focus on its lifecycle and the associated costs and benefits. And there are opportunity costs: Fixing a particular code smell means that future features of the application will get delayed. And the question is not only at what point in the future, in some (YAGNI) cases perhaps never, our now improved code quality let us catch up with otherwise earlier feature implementations: The extended time-to-market for our new features also comes at a price. So to decide what is actually best, it is not enough to look only at the technical side of a software project. The time-to-market (or time-to-use) cost, which has nothing to do with engineering per se, must also be taken into account. When deciding when a particular code smell should be fixed, both technical and business aspects are important: Technical effort and benefit must be evaluated and weighed against the aforementioned opportunity costs of feature delays. That is why good cooperation and open communication between engineers and business people within a company is important. If this is not the case, well, this is another smell that perhaps needs to be refactored first. If it is worthwhile ...
- 4y ago