6 ms·

From years of experience, I detect in the tone of this piece a certain notion that product managers / non-technical people tend to form when working with develo

From years of experience, I detect in the tone of this piece a certain notion that product managers / non-technical people tend to form when working with developers - namely, that developers don't care about speed-to-market and would rather agonize and winge over perfect architecture and coding standards... What I think you'll find, more often than not, on the business end of this attitude is a developer(s) patiently trying to explain that speed-to-market is, in fact, directly related to the technical debt accrued on the project for all but the most static and inconsequential things. We must think and communicate about technical debt precisely the way we do to keep errant PMs from drifting off into the Ice Cream Sea of Candyland where all of the half-thought-through ideas they demand be implemented immediately by cutting all corners have no impact on the next set of half-thought-through ideas they want implemented.

moron4hire 11y ago
New PMs are like children, they tend to only learn the fire is hot by actually getting burnt. Instead of digging my heels in on not giving such PMs everything they want, I try to offer alternatives and put the choice on them: they can have this feature today and in 6 months we grind to a halt because we can't fit in anything new, or we slow down just half a beat and do it right the first time. "Up to you, buddy," I say. It happens with jr. devs, too. They want to use a singleton to solve a problem, or they want to forgo using any sort of referential constraints in their schemas. Of course, the PMs and jr. devs always choose the shortcuts. I help them both pick up the pieces afterwards, but I never work overtime for it. The point is to make it clear that nobody other than themselves is responsible for their own mistakes. They led us into the mess, they can lead us out. After that, everyone seems to get along a lot better and everyone seems super keen on having discussions about the "right" way to do things and how to fit things into the current state of the project correctly.
- dccoolgai 11y ago
  || they can have this feature today and in 6 months we grind to a halt Buy some daisies and chocolate for the PMs you work with... because here's how that would go over with the ones I've had: PM: "Yes! Cut all corners and get it done today!" ...6 Months go by... PM: "I came up with a new idea for that! Today, please!" DEV: "But remember..." PM:"Today, thanks!"
  - moron4hire 11y ago
    You do a job. There is a reason you are there, and it's not to write code. It's to fulfill requests. Feel free to provide advice on how best to fulfill those requests, provide feedback, ask for clarification, etc. But at the end of the day, all you do is what you are told. It's not to anticipate what they will want in 6 months, because you'll be wrong just as often as right and you'll be in the same scenario. Just do your job. So when you're told to cut corners today, then in 6 months you can't make magic happen to grant their every whim, you have to let it blow up. They want to be the leader. They are responsible for the failings of the team. You have to play chicken with them. Because every time you capitulate, all they know is "I got what I wanted". They don't care how much you complained or how many hours off the clock you worked. And honestly, if you tell them it can't be done overnight, and then you do it overnight, you're a liar and they won't trust your judgement ever again. When you say, "can't do it", you have to not do it. Don't make magic happen. Or just don't work at such places. I have thankfully been out of that bullshit for three years running now.
    - omouse 11y ago
      That's the everyday struggle; as developers we can produce so much wealth just by typing at a keyboard. Yet we let ourselves be controlled by people who don't know what's what and can't even prove their ideas have any return on investment. As you say, don't make magic happen. It doesn't matter how cool it would be if, or how you think you'll show them your ideas are better; when you say "it cannot be done" don't go and try and do it. Don't let the manager bully you and don't let them try and get another developer to tackle the impossible. I've had that happen to me where I said it will take X amount of time to do it so let's not do it till next sprint. Then the manager went around my back when I was gone for a day and gave the task to another dev. The dev, who caused the mess, of course was able to fix it within an hour. Why did I say X amount of time? To cleanup and make sure the bug stays fixed. When you work with other developers, actually work together. Stand up for them, don't make bad comments about them, and always stick together when you're asked to do the impossible.
      - sokoloff 11y ago
- brlewis 11y ago
  A less condescending way to make that first statement would be, PMs learn from experience.
  - moron4hire 11y ago
    I suppose I could have said "most people" instead of "new PMs".
    - brlewis 11y ago
      Yes, that would do it too. Generally I agree with you on the principle of using communication to help people learn from experience. I wrote about it here: https://medium.com/@brlewis/fighting-technical-debt-in-an-agile-team-c48662abf76e https://medium.com/@brlewis/fighting-technical-debt-in-an-ag...
      - MaysonL 11y ago
        Yes, learning some lessons from other people's experiences is often much less painful…
rsp1984 11y ago
From years of my experience, both in big corporate tech and startups, smart Engineers will always find business reasons to sell you their tech-debt free perfect rainbow unicorn architecture. Even worse, if you're then not equally technical as a manager you will never know whether you've made a solid choice by aligning with or against the engineer's view, and even worse your engineers will quickly take on a "see, I told you so" stance should things work out not perfectly under an agile model. Edit: I should add that I am an engineer myself.
- bunderbunder 11y ago
  I've seen entire products - established, successful products - sunk by a single decision to let the engineers build a gold-plated replacement for some component that had a messy architecture and eye-watering code on the inside but otherwise wasn't broken and didn't need fixing. This is a spot where I'm definitely in line with the Scrum position: If it's really causing problems, then the developers should have no problem making a reasonable business case for fixing them. If working on it's really causing that much pain, then the developers will figure out a way to quietly fix it in a way that doesn't (and needn't) vex the product owner. If neither of those is the case then you best let sleeping bears lie. (I'm an engineer too.)
  - pekk 11y ago
    Just because you don't think anything is wrong in terms of external acceptance criteria, does not mean that there is not something wrong with the code that is of real consequence. Contrarian anecdotes aside, the reason everyone knows the phrase "technical debt" is because SO MANY of us see projects wrecked by greedily demanding many features and changes as fast as possible in a continuous crunch mode, without considering long-term costs like defect rate or turnaround time on bugfix and feature implementations... or developer burnout. It's better not to assume that developers are blathering when they ask for formal permission to carry out QA or maintenance tasks or upgrades, if they are the people who know what the work looks like on the ground level. If you are putting lots of time pressure on developers and implying that heads will roll if aggressive deadlines are missed, it doesn't make sense also to leave it up to those developers to magically find the time to fix lurking internal time-bombs. This makes products worse, it makes developers' lives worse and developers are stuck with the blame for something they can't control. Maybe as a PM or whatever that suits you, to dump all the risk in the laps of your developers. But if you are yourself an engineer you should not make yourself part of this problem.

moron4hire 11y ago

New PMs are like children, they tend to only learn the fire is hot by actually getting burnt. Instead of digging my heels in on not giving such PMs everything they want, I try to offer alternatives and put the choice on them: they can have this feature today and in 6 months we grind to a halt because we can't fit in anything new, or we slow down just half a beat and do it right the first time. "Up to you, buddy," I say. It happens with jr. devs, too. They want to use a singleton to solve a problem, or they want to forgo using any sort of referential constraints in their schemas. Of course, the PMs and jr. devs always choose the shortcuts. I help them both pick up the pieces afterwards, but I never work overtime for it. The point is to make it clear that nobody other than themselves is responsible for their own mistakes. They led us into the mess, they can lead us out. After that, everyone seems to get along a lot better and everyone seems super keen on having discussions about the "right" way to do things and how to fit things into the current state of the project correctly.

dccoolgai 11y ago
|| they can have this feature today and in 6 months we grind to a halt Buy some daisies and chocolate for the PMs you work with... because here's how that would go over with the ones I've had: PM: "Yes! Cut all corners and get it done today!" ...6 Months go by... PM: "I came up with a new idea for that! Today, please!" DEV: "But remember..." PM:"Today, thanks!"
- moron4hire 11y ago
  You do a job. There is a reason you are there, and it's not to write code. It's to fulfill requests. Feel free to provide advice on how best to fulfill those requests, provide feedback, ask for clarification, etc. But at the end of the day, all you do is what you are told. It's not to anticipate what they will want in 6 months, because you'll be wrong just as often as right and you'll be in the same scenario. Just do your job. So when you're told to cut corners today, then in 6 months you can't make magic happen to grant their every whim, you have to let it blow up. They want to be the leader. They are responsible for the failings of the team. You have to play chicken with them. Because every time you capitulate, all they know is "I got what I wanted". They don't care how much you complained or how many hours off the clock you worked. And honestly, if you tell them it can't be done overnight, and then you do it overnight, you're a liar and they won't trust your judgement ever again. When you say, "can't do it", you have to not do it. Don't make magic happen. Or just don't work at such places. I have thankfully been out of that bullshit for three years running now.
  - omouse 11y ago
    That's the everyday struggle; as developers we can produce so much wealth just by typing at a keyboard. Yet we let ourselves be controlled by people who don't know what's what and can't even prove their ideas have any return on investment. As you say, don't make magic happen. It doesn't matter how cool it would be if, or how you think you'll show them your ideas are better; when you say "it cannot be done" don't go and try and do it. Don't let the manager bully you and don't let them try and get another developer to tackle the impossible. I've had that happen to me where I said it will take X amount of time to do it so let's not do it till next sprint. Then the manager went around my back when I was gone for a day and gave the task to another dev. The dev, who caused the mess, of course was able to fix it within an hour. Why did I say X amount of time? To cleanup and make sure the bug stays fixed. When you work with other developers, actually work together. Stand up for them, don't make bad comments about them, and always stick together when you're asked to do the impossible.
    - sokoloff 11y ago
brlewis 11y ago
A less condescending way to make that first statement would be, PMs learn from experience.
- moron4hire 11y ago
  I suppose I could have said "most people" instead of "new PMs".
  - brlewis 11y ago
    Yes, that would do it too. Generally I agree with you on the principle of using communication to help people learn from experience. I wrote about it here: https://medium.com/@brlewis/fighting-technical-debt-in-an-agile-team-c48662abf76e https://medium.com/@brlewis/fighting-technical-debt-in-an-ag...
    - MaysonL 11y ago
      Yes, learning some lessons from other people's experiences is often much less painful…

rsp1984 11y ago

From years of my experience, both in big corporate tech and startups, smart Engineers will always find business reasons to sell you their tech-debt free perfect rainbow unicorn architecture. Even worse, if you're then not equally technical as a manager you will never know whether you've made a solid choice by aligning with or against the engineer's view, and even worse your engineers will quickly take on a "see, I told you so" stance should things work out not perfectly under an agile model. Edit: I should add that I am an engineer myself.

bunderbunder 11y ago
I've seen entire products - established, successful products - sunk by a single decision to let the engineers build a gold-plated replacement for some component that had a messy architecture and eye-watering code on the inside but otherwise wasn't broken and didn't need fixing. This is a spot where I'm definitely in line with the Scrum position: If it's really causing problems, then the developers should have no problem making a reasonable business case for fixing them. If working on it's really causing that much pain, then the developers will figure out a way to quietly fix it in a way that doesn't (and needn't) vex the product owner. If neither of those is the case then you best let sleeping bears lie. (I'm an engineer too.)
- pekk 11y ago
  Just because you don't think anything is wrong in terms of external acceptance criteria, does not mean that there is not something wrong with the code that is of real consequence. Contrarian anecdotes aside, the reason everyone knows the phrase "technical debt" is because SO MANY of us see projects wrecked by greedily demanding many features and changes as fast as possible in a continuous crunch mode, without considering long-term costs like defect rate or turnaround time on bugfix and feature implementations... or developer burnout. It's better not to assume that developers are blathering when they ask for formal permission to carry out QA or maintenance tasks or upgrades, if they are the people who know what the work looks like on the ground level. If you are putting lots of time pressure on developers and implying that heads will roll if aggressive deadlines are missed, it doesn't make sense also to leave it up to those developers to magically find the time to fix lurking internal time-bombs. This makes products worse, it makes developers' lives worse and developers are stuck with the blame for something they can't control. Maybe as a PM or whatever that suits you, to dump all the risk in the laps of your developers. But if you are yourself an engineer you should not make yourself part of this problem.