7 ms·

The article is not saying "big feature" pipelines (where there is coordination across several teams) are inherently bad. The article is disparaging that proces

The article is not saying "big feature" pipelines (where there is coordination across several teams) are inherently bad. The article is disparaging that process if it is the only process. (And I've worked at companies where this was nearly true). There must be efforts to experiment and refine (and possibly remove) existing features. There must be efforts to refactor and improve existing code, to make it easier to maintain, less painful to be on-call, and make it possible to add subsequent features without breaking existing functionality. You have to be able to do both large and incremental work to improve, in other words.

tomnipotent 7y ago
> There must be efforts to refactor and improve existing code Some of the best tech management advice I received was to never get explicit approval for refactoring from your immediate boss - whether you're the line engineer or CTO. Instead, you pad dates as needed to get the refactoring work done implicitly. This has yet to fail me. Granted, I don't work in embedded systems and my code is deployed on owned & operated servers that's easy to update.
- taeric 7y ago
  I really push this with my team. I will flat out reject stories that are "refactor". Instead, just do it, and spare us the prioritization debate. If you really can't get it done, you'll find out without eating everyone's time to debate whether you can. And if you get it done, great, things have improved. Now, you will have other priorities. Make sure you aren't dropping them. But most things are communication based. In time, you will find ways to improve without disrupting. Backwards and forwards compatibility will be tools, not burdens. Stability of the core will similarly work for you, such that you may start choosing to leave parts alone as you focus on peripheral changes that will have clearer impact to users. The stability part is hard to overstate. There is a reason the Arduino uno is relatively unchanged. There is massive value in having a stationary target for what you are building. Custom everything down the line is an easy recipe for failure. Even if there are improvements that can be made down that line.
  - quanticle 7y ago
    > I will flat out reject stories that are "refactor". Instead, just do it, and spare us the prioritization debate. Or alternatively, don't, because the message from management is that maintenance takes a back seat to shipping new features. For example, my team has been using a home-brewed NodeJS-to-Kafka library. Now, everyone on the team understands that this library is suboptimal in a number of ways (most notably because the developer who wrote it is no longer with the company) and that it should be replaced by some alternative from Github. But this is a change that will require quite a few downstream changes (mostly because the way the existing library was used was not well-factored). There's no way of doing this change without it being a separate story. It's just too big a change. It's also not really something that is easy to do efficiently in an incremental fashion -- having two Kafka libraries simultaneously in the codebase is an even worse situation to be in than having a single, suboptimal library. And management is not willing to authorize a separate story for a "refactoring" such as this one, even though it would result in significant operational savings (less memory usage, fewer server restarts, etc). So we bumble along, waiting until the pain becomes so severe that we're ordered to embark on a hasty rework in order to hurriedly patch in the new library when the system finally melts down.
- mLuby 7y ago
  Good for you for leaving things better than you found them. But when management compares your output with Cowboy Chris, the fastest code-slinger in the West, they'll think he's better for the company even though he's racking up tech debt on his journey. Ideally you'd get credit for the good work you do that makes the whole team more efficient.
  - tomnipotent 7y ago
    I am "management", whatever that means. Sounds like you're pretty jaded about an experience you had. Not all advice works for all people in all situations, but this has proven great for me.
  - mokus 7y ago
    being (sustainably) fast and producing quality code often go hand in hand. If management doesn’t know Cowboy Chris generates most of the debugging time, that’s a management problem. A good management team is aware of which people are fast in short sprints but end up tangling things up on longer efforts, which people take time to build steam but never hit that slow-down, and which people fit other patterns (for example, the extremely rare fixers who can take Cowboy Chris’s shit and funnel it into something useful, or the even rarer speed demons who can sprint like that forever because they are like Chris but they work cleanly too) Good engineers, given the chance, will find and stick with those managers too.
  - dragonwriter 7y ago
    > But when management compares your output with Cowboy Chris, the fastest code-slinger in the West, they'll think he's better for the company even though he's racking up tech debt on his journey. Maybe. OTOH, not only can focussed refactoring make delivering the features it is associated with faster, but refactoring—delivery-focused or not—is a really good way tonbuild knowledge of and proficiency with a code base, so if you aren't doing huge quantities of non-germane refactoring, it can actually be a personal delivery-speed enhancer, as well as the benefits for the team.
- ldng 7y ago
  My experience is that implicity is a huge problem as it's too often taken for granted and precisely not valued. Only when you stop doing people realize that since Jeff is on long leave server aren't updated and we've been hacked or that Lucy quited and everything seem to crawl to a halt because she implicitly was doing housekeeping on the database. It might not have failed you yet but be sure the day it does there a good chance it will be spectacular.
  - tomnipotent 7y ago
    These are all expected and desirable outcomes. Sometimes technical debt is not worth paying off until your hand is forced, like in these examples. A large part of management is making the implicit explicit, and communicating the outcome of these efforts. None of these examples have anything to do with refactoring code, specifically, and the challenges faced within that work.
    - notyourday 7y ago
      The first sentence contradicts the other two and it contradicts the previous position where refactoring was done implicitly without anyone above in the org being aware of it.
      - tomnipotent 7y ago
        See my last sentence. The OP listed examples of process failure, not refactoring.
- mokus 7y ago
  I do work on embedded systems and it works there too. Much better in any kind of project though is if you can get a management team that actually sees the value in it. I still consider it pretty much mandatory to build core system improvement into feature estimates but by being more explicit and interactive about it you can get good feedback to refine your own estimates of what parts are even worth improving. It may be that the product line that uses the subsystem you want to improve is about to go a new direction, for example, and the better thing to do is to start preparing for that subsystem to go away.
- notyourday 7y ago
  > Some of the best tech management advice I received was to never get explicit approval for refactoring from your immediate boss - whether you're the line engineer or CTO. Instead, you pad dates as needed to get the refactoring work done implicitly. This is the thing that I cannot agree with what so ever. Companies do not employ developers to write beautiful code. Companies employ developers to write code to support business. Every single code base that shipped contains warts that became obvious as soon as the final commit was one, which means that refactoring is a cost and costs need to be accounted for and prioritized according to business objectives ( which at the end is making money -- the money that pays developers salaries ).
  - tomnipotent 7y ago
    Show me great companies that follow this philosophy? You definitely won't find them among FAANG, or most of the companies the HN crowd lean towards. There's a limit to when the invasiveness of bean counting is useful, and finding that limit is paramount.
    - notyourday 7y ago
      I'm not following - Is it your claim that among FAANGs it is a normal practice to say "This will take X weeks" when in reality it will take Y weeks to implement and K weeks to refactor something else where Y + K is X?
      - tomnipotent 7y ago
        That these companies don't treat engineers as a cost structure the way you were talking about. This creates a drastically different culture since tech has a seat at the table, and the CFO can't just willy-nilly makes demands that impact the entire engineering organization without consent. It makes a big difference.
        notyourday 7y ago
        > That these companies don't treat engineers as a cost structure the way you were talking about. That's absurd. The reason those companies are making money is because they are costing every single thing. That's the reason why tech gets a seat at the table -- it is a cost and its top of the line managers understand that this is a liability and drive that understanding through the entire tech organization.
- hamiltont 7y ago
  A challenge I keep hitting with this is non-technical team asking 'why it takes this long' anytime the provided date is >X (for some X is a day, for others it's a week). They want to understand the internals of the ask so they can then nitpick that "well that's not needed". Fundamentally it's a lack of trust IMO, but any tips on addressing this would be welcome :-)
  - tomnipotent 7y ago
    > Fundamentally it's a lack of trust IMO Which is usually a failure of communication. The whole "just trust us" bit doesn't work, and it takes real work to build a rapport with your stakeholders to earn "blind" trust, which is what most people are really asking for when they say "just trust us". This almost never happens, unless people have been working with each other for many years. > then nitpick that "well that's not needed" First, ask questions. Find out why they're willing to put energy into this - most people are not wasteful when they push back on things (most). Maybe their boss is riding their ass, and it's CYA. Maybe they're just stating a preference, so I'll ask questions to make this explicit ("So you just prefer it this way? No data? No customer feedback? Your boss didn't ask?"). Second, socialize things early and often. Tell people weeks, months, quarters in advance about some technical debt you're eventually going to get around to paying off. This gives people time to vent, challenge things, or say they're stupid. Use this time to refine your story, and get better at telling it in a way that gets the least resistance (don't need support, just fewer detractors). Sometimes that "socializing" is complaining about a shared frustration. "Ugh, System X gobbled up Sharon's purchase order again and she has to spend another two hours after working salvaging things. Really wish they'd let us spend time fixing this, but you know how it goes." By the time I've scheduled a meeting with stakeholders to discuss something (especially something I know will be difficult for them to see value in), I make sure I've individually discussed it with everyone in the room. When they see less disagreement between each other, there's less negative energy to build off. There may not be any positive energy, but that's much easier to deal with.
    - hamiltont 7y ago
      > Which is usually a failure of communication This is interesting and will take some introspection, but perhaps I can improve these situations by fostering better communication. Thanks for taking the time to respond.
- notatoad 7y ago
  yes, refactoring is never something that I would plan as a standalone thing - it's just a part of building features or fixing bugs. If you're going to be working on a part of the codebase that you know is difficult to work with, you need to pad your estimate whether you're planning to refactor it or not - either you use the time to do the refactor, or you use the time to sort out the bugs you introduced by working on scary code without refactoring.
dragonwriter 7y ago
The practices you discuss are incidental, the real criticism the article makes is that there must be focus on measuring and delivering customer value; that h focus must be on impact rather than a train of features.

tomnipotent 7y ago

> There must be efforts to refactor and improve existing code Some of the best tech management advice I received was to never get explicit approval for refactoring from your immediate boss - whether you're the line engineer or CTO. Instead, you pad dates as needed to get the refactoring work done implicitly. This has yet to fail me. Granted, I don't work in embedded systems and my code is deployed on owned & operated servers that's easy to update.

taeric 7y ago
I really push this with my team. I will flat out reject stories that are "refactor". Instead, just do it, and spare us the prioritization debate. If you really can't get it done, you'll find out without eating everyone's time to debate whether you can. And if you get it done, great, things have improved. Now, you will have other priorities. Make sure you aren't dropping them. But most things are communication based. In time, you will find ways to improve without disrupting. Backwards and forwards compatibility will be tools, not burdens. Stability of the core will similarly work for you, such that you may start choosing to leave parts alone as you focus on peripheral changes that will have clearer impact to users. The stability part is hard to overstate. There is a reason the Arduino uno is relatively unchanged. There is massive value in having a stationary target for what you are building. Custom everything down the line is an easy recipe for failure. Even if there are improvements that can be made down that line.
- quanticle 7y ago
  > I will flat out reject stories that are "refactor". Instead, just do it, and spare us the prioritization debate. Or alternatively, don't, because the message from management is that maintenance takes a back seat to shipping new features. For example, my team has been using a home-brewed NodeJS-to-Kafka library. Now, everyone on the team understands that this library is suboptimal in a number of ways (most notably because the developer who wrote it is no longer with the company) and that it should be replaced by some alternative from Github. But this is a change that will require quite a few downstream changes (mostly because the way the existing library was used was not well-factored). There's no way of doing this change without it being a separate story. It's just too big a change. It's also not really something that is easy to do efficiently in an incremental fashion -- having two Kafka libraries simultaneously in the codebase is an even worse situation to be in than having a single, suboptimal library. And management is not willing to authorize a separate story for a "refactoring" such as this one, even though it would result in significant operational savings (less memory usage, fewer server restarts, etc). So we bumble along, waiting until the pain becomes so severe that we're ordered to embark on a hasty rework in order to hurriedly patch in the new library when the system finally melts down.
mLuby 7y ago
Good for you for leaving things better than you found them. But when management compares your output with Cowboy Chris, the fastest code-slinger in the West, they'll think he's better for the company even though he's racking up tech debt on his journey. Ideally you'd get credit for the good work you do that makes the whole team more efficient.
- tomnipotent 7y ago
  I am "management", whatever that means. Sounds like you're pretty jaded about an experience you had. Not all advice works for all people in all situations, but this has proven great for me.
- mokus 7y ago
  being (sustainably) fast and producing quality code often go hand in hand. If management doesn’t know Cowboy Chris generates most of the debugging time, that’s a management problem. A good management team is aware of which people are fast in short sprints but end up tangling things up on longer efforts, which people take time to build steam but never hit that slow-down, and which people fit other patterns (for example, the extremely rare fixers who can take Cowboy Chris’s shit and funnel it into something useful, or the even rarer speed demons who can sprint like that forever because they are like Chris but they work cleanly too) Good engineers, given the chance, will find and stick with those managers too.
- dragonwriter 7y ago
  > But when management compares your output with Cowboy Chris, the fastest code-slinger in the West, they'll think he's better for the company even though he's racking up tech debt on his journey. Maybe. OTOH, not only can focussed refactoring make delivering the features it is associated with faster, but refactoring—delivery-focused or not—is a really good way tonbuild knowledge of and proficiency with a code base, so if you aren't doing huge quantities of non-germane refactoring, it can actually be a personal delivery-speed enhancer, as well as the benefits for the team.
ldng 7y ago
My experience is that implicity is a huge problem as it's too often taken for granted and precisely not valued. Only when you stop doing people realize that since Jeff is on long leave server aren't updated and we've been hacked or that Lucy quited and everything seem to crawl to a halt because she implicitly was doing housekeeping on the database. It might not have failed you yet but be sure the day it does there a good chance it will be spectacular.
- tomnipotent 7y ago
  These are all expected and desirable outcomes. Sometimes technical debt is not worth paying off until your hand is forced, like in these examples. A large part of management is making the implicit explicit, and communicating the outcome of these efforts. None of these examples have anything to do with refactoring code, specifically, and the challenges faced within that work.
  - notyourday 7y ago
    The first sentence contradicts the other two and it contradicts the previous position where refactoring was done implicitly without anyone above in the org being aware of it.
    - tomnipotent 7y ago
      See my last sentence. The OP listed examples of process failure, not refactoring.
mokus 7y ago
I do work on embedded systems and it works there too. Much better in any kind of project though is if you can get a management team that actually sees the value in it. I still consider it pretty much mandatory to build core system improvement into feature estimates but by being more explicit and interactive about it you can get good feedback to refine your own estimates of what parts are even worth improving. It may be that the product line that uses the subsystem you want to improve is about to go a new direction, for example, and the better thing to do is to start preparing for that subsystem to go away.
notyourday 7y ago
> Some of the best tech management advice I received was to never get explicit approval for refactoring from your immediate boss - whether you're the line engineer or CTO. Instead, you pad dates as needed to get the refactoring work done implicitly. This is the thing that I cannot agree with what so ever. Companies do not employ developers to write beautiful code. Companies employ developers to write code to support business. Every single code base that shipped contains warts that became obvious as soon as the final commit was one, which means that refactoring is a cost and costs need to be accounted for and prioritized according to business objectives ( which at the end is making money -- the money that pays developers salaries ).
- tomnipotent 7y ago
  Show me great companies that follow this philosophy? You definitely won't find them among FAANG, or most of the companies the HN crowd lean towards. There's a limit to when the invasiveness of bean counting is useful, and finding that limit is paramount.
  - notyourday 7y ago
    I'm not following - Is it your claim that among FAANGs it is a normal practice to say "This will take X weeks" when in reality it will take Y weeks to implement and K weeks to refactor something else where Y + K is X?
    - tomnipotent 7y ago
      That these companies don't treat engineers as a cost structure the way you were talking about. This creates a drastically different culture since tech has a seat at the table, and the CFO can't just willy-nilly makes demands that impact the entire engineering organization without consent. It makes a big difference.
      - notyourday 7y ago
        > That these companies don't treat engineers as a cost structure the way you were talking about. That's absurd. The reason those companies are making money is because they are costing every single thing. That's the reason why tech gets a seat at the table -- it is a cost and its top of the line managers understand that this is a liability and drive that understanding through the entire tech organization.
hamiltont 7y ago
A challenge I keep hitting with this is non-technical team asking 'why it takes this long' anytime the provided date is >X (for some X is a day, for others it's a week). They want to understand the internals of the ask so they can then nitpick that "well that's not needed". Fundamentally it's a lack of trust IMO, but any tips on addressing this would be welcome :-)
- tomnipotent 7y ago
  > Fundamentally it's a lack of trust IMO Which is usually a failure of communication. The whole "just trust us" bit doesn't work, and it takes real work to build a rapport with your stakeholders to earn "blind" trust, which is what most people are really asking for when they say "just trust us". This almost never happens, unless people have been working with each other for many years. > then nitpick that "well that's not needed" First, ask questions. Find out why they're willing to put energy into this - most people are not wasteful when they push back on things (most). Maybe their boss is riding their ass, and it's CYA. Maybe they're just stating a preference, so I'll ask questions to make this explicit ("So you just prefer it this way? No data? No customer feedback? Your boss didn't ask?"). Second, socialize things early and often. Tell people weeks, months, quarters in advance about some technical debt you're eventually going to get around to paying off. This gives people time to vent, challenge things, or say they're stupid. Use this time to refine your story, and get better at telling it in a way that gets the least resistance (don't need support, just fewer detractors). Sometimes that "socializing" is complaining about a shared frustration. "Ugh, System X gobbled up Sharon's purchase order again and she has to spend another two hours after working salvaging things. Really wish they'd let us spend time fixing this, but you know how it goes." By the time I've scheduled a meeting with stakeholders to discuss something (especially something I know will be difficult for them to see value in), I make sure I've individually discussed it with everyone in the room. When they see less disagreement between each other, there's less negative energy to build off. There may not be any positive energy, but that's much easier to deal with.
  - hamiltont 7y ago
    > Which is usually a failure of communication This is interesting and will take some introspection, but perhaps I can improve these situations by fostering better communication. Thanks for taking the time to respond.
notatoad 7y ago
yes, refactoring is never something that I would plan as a standalone thing - it's just a part of building features or fixing bugs. If you're going to be working on a part of the codebase that you know is difficult to work with, you need to pad your estimate whether you're planning to refactor it or not - either you use the time to do the refactor, or you use the time to sort out the bugs you introduced by working on scary code without refactoring.

dragonwriter 7y ago

The practices you discuss are incidental, the real criticism the article makes is that there must be focus on measuring and delivering customer value; that h focus must be on impact rather than a train of features.