This why any good engineer would bake it into their estimates when working around the area. I think Martin Fowler covers this in Refactoring. Eiher that or it was Kent Beck in TDD. Both books complement each other really well.
A good civil engineer doesn’t ask a Project Manager if they can add in structural supports. A good software engineer shouldn’t ask to build things right.
“Before we build x, we need to adapt the foundations by resolving x problem. If we don’t get this right, it’ll increase the chances of bugs surfacing in production and would make our team look like a joke.”
Bad PO: “So it will only increase the chance of bugs if we don’t do it? There won’t necessarily be any. So we can skip it and just put the feature in.”
I hope you have a good PO who is on the same page as you, but to a bad PO, it still sounds optional.
A civil engineer doesn’t say “If we don’t put supports there’s a chance the ceiling will fall in and people may die,” because history has shown there are plenty of unscrupulous project managers who are quite willing to take construction risks, even with people’s lives. As a result of this there are now plenty of laws in construction, and a civil engineer has a convenient fallback of saying “If we don’t put supports it won’t pass inspection, and we won’t get paid.”
Everyone wants to get paid.
In software we don’t have many laws we can fall back on to justify our work, but we can still treat our tech debt and refactoring as if it’s equally mandatory.
“To add feature x, we need to resolve problem y. The feature can’t be added until we’ve completed this prerequisite.”
You’re trusting a PO to decide on how you build? They ain’t coders. They decide on value, you estimate and build and they prioritise based on the information you provide. POs aren’t the boss of devs. That’s usually engineering managers. You are both specialists in your field. You don’t lecture them on value and how pointless a feature is, you size it, and using velocity they can anticipate how much will likely be delivered in next sprint. If they really object, “if you feel you can build it in 1 day, go ahead, ill give you access. I have no idea how that could be done”
PO wouldn’t like it during live incident when shit goes wrong that you suggest “I did highlight the risk of this occurring and proposed mitigation steps but was overruled”.
“Are you willing to own the risk? If so, what will it look like? Can you budget additional time for addressing these bugs, and draft contingency plans?”
“True. It’ll be perfectly fine, and because of that, you won’t need me on call when it all goes dramatically wrong. If you need access to the repo, I’ll add you in though. Good luck.”
Or, if you’ve worked together a while “like I overthought it when we worked on x, and y went wrong, and I called it before it happened. Turns out I’m quite good at seeing car crashes in advance.”
“Why are we only learning about this now? How long has this requirement been known? I think we need to look into the process that work comes into the team otherwise, if we don’t learn, we are going to take the website down and cost the company thousands/millions. It’s worth working with the business to get a batter understanding of upcoming requirements so we know what’s going to be needed in a months time”. There is a reason retros exist. Oh, and you have to be good at teasing out real deadlines vs arbitrary deadlines made up with no justifiable reason.
“You ask me how long it’ll take, and it’s 3 days. You probably need to manage expectations on this. Maybe let them know the risks of x, y and z and why it will take this long”.
Thats a scheduling issue on your end. I’ve given the time estimate my team needs. You can adjust expectations and shift around my allocated time but it will take x hours no matter what.
There is no putting up with half of these complaints. They just arent real things that occur in a workplace.
The big difference is a civil/structural engineer has to individually certify a plan sets and take legal responsibility for it. The project manager can’t override them.
They can fire them and hire another engineer, but even if they found someone to stamp bad plans for a fee, the original engineer could report the new engineer and have their credentials yanked.
We don’t have that in software engineering. And outside of critical software we don’t need it. When the audio fucks up in Teams and you have to leave and re-enter the meeting, people don’t die.
Fuck Teams. The buggiest, most crash prone mess I’ve even been forced to use. They keep bolting on new, unnecessary “features” that only selectively work on some of their “supported” platforms.
We don’t have that in software engineering. And outside of critical software we don’t need it. When the audio fucks up in Teams and you have to leave and re-enter the meeting, people don’t die.
I had a co-worker who was writing remote control software for a baseball-throwing machine. Not exactly “critical software” but he ended up firing a 125 mph knuckleball a foot above a 10-year-old kid’s head.
I’ve always been uncomfortable, honestly, with calling software developers “engineers”. Partly that’s because it’s actually illegal to call a non-PEng role an “engineer” in some jurisdictions (most of Canada), but I think this comment is an excellent point of distinction to make between PEng and other roles.
Legal responsibility along with regulatory requirements. There’s a reason everyone* trusts elevators and airplanes but shouldn’t trust most software.
I don’t know those guys so they can say what they want. We don’t just ship. We code, review, test and only then deploy. I will build this the only way I can see and it’ll take 3 days. Want me to start this?
The difference there is that our project manager guy is afraid they’re gonna go to prison if they don’t let you add those supports and something goes wrong. But for the software dude, building things properly is unfortunately mostly a concern for you and the other software engineers, and mr project manager doesn’t have that much of an incentive to let you do that
I find project managers don’t want to be responsible for building shit that is flaky on prod. Either the consultancy reputation or team reputation becomes mud and their promotion opportunities vanish.
yeah but when I do that, people get mad at me and ask “why number so big”, then when I explain they say “ok but what if there aren’t any issues” and then they make schedules based on that clearly incorrect number
“If you can give me that issue free codebase, I’m happy to do that, but failing that, it takes 3 days to add that feature that is akin to the leaning tower of Piza taped together with duct tape. There is only so much tech debt you can pile on until you are in code hell, and unfortunately, we are.”
If they do some weird ass schedule “well, you can write down that if you wish, feel free to write down that my other car is a Bugatti, if we are just theorising on a perfect unicorn world”.
This why any good engineer would bake it into their estimates when working around the area. I think Martin Fowler covers this in Refactoring. Eiher that or it was Kent Beck in TDD. Both books complement each other really well.
A good civil engineer doesn’t ask a Project Manager if they can add in structural supports. A good software engineer shouldn’t ask to build things right.
“Before we build x, we need to adapt the foundations by resolving x problem. If we don’t get this right, it’ll increase the chances of bugs surfacing in production and would make our team look like a joke.”
Bad PO: “So it will only increase the chance of bugs if we don’t do it? There won’t necessarily be any. So we can skip it and just put the feature in.”
I hope you have a good PO who is on the same page as you, but to a bad PO, it still sounds optional.
A civil engineer doesn’t say “If we don’t put supports there’s a chance the ceiling will fall in and people may die,” because history has shown there are plenty of unscrupulous project managers who are quite willing to take construction risks, even with people’s lives. As a result of this there are now plenty of laws in construction, and a civil engineer has a convenient fallback of saying “If we don’t put supports it won’t pass inspection, and we won’t get paid.”
Everyone wants to get paid.
In software we don’t have many laws we can fall back on to justify our work, but we can still treat our tech debt and refactoring as if it’s equally mandatory.
“To add feature x, we need to resolve problem y. The feature can’t be added until we’ve completed this prerequisite.”
You’re trusting a PO to decide on how you build? They ain’t coders. They decide on value, you estimate and build and they prioritise based on the information you provide. POs aren’t the boss of devs. That’s usually engineering managers. You are both specialists in your field. You don’t lecture them on value and how pointless a feature is, you size it, and using velocity they can anticipate how much will likely be delivered in next sprint. If they really object, “if you feel you can build it in 1 day, go ahead, ill give you access. I have no idea how that could be done”
PO wouldn’t like it during live incident when shit goes wrong that you suggest “I did highlight the risk of this occurring and proposed mitigation steps but was overruled”.
Just build and deploy it! We have the shareholders to think of!
This person has high level management energy
Me? No. But I’ve met plenty of those types.
“Are you willing to own the risk? If so, what will it look like? Can you budget additional time for addressing these bugs, and draft contingency plans?”
“You’re overthinking it” - real response from my management
“True. It’ll be perfectly fine, and because of that, you won’t need me on call when it all goes dramatically wrong. If you need access to the repo, I’ll add you in though. Good luck.”
Or, if you’ve worked together a while “like I overthought it when we worked on x, and y went wrong, and I called it before it happened. Turns out I’m quite good at seeing car crashes in advance.”
*Sticks fingers in ears* Can’t hear you!
“I only know 1 (credible) way to build it. I’ll take x days. I’ll go right ahead with that.”
We need it yesterday! Just get it done!
“Why are we only learning about this now? How long has this requirement been known? I think we need to look into the process that work comes into the team otherwise, if we don’t learn, we are going to take the website down and cost the company thousands/millions. It’s worth working with the business to get a batter understanding of upcoming requirements so we know what’s going to be needed in a months time”. There is a reason retros exist. Oh, and you have to be good at teasing out real deadlines vs arbitrary deadlines made up with no justifiable reason.
“You ask me how long it’ll take, and it’s 3 days. You probably need to manage expectations on this. Maybe let them know the risks of x, y and z and why it will take this long”.
Thats a scheduling issue on your end. I’ve given the time estimate my team needs. You can adjust expectations and shift around my allocated time but it will take x hours no matter what.
There is no putting up with half of these complaints. They just arent real things that occur in a workplace.
The big difference is a civil/structural engineer has to individually certify a plan sets and take legal responsibility for it. The project manager can’t override them.
They can fire them and hire another engineer, but even if they found someone to stamp bad plans for a fee, the original engineer could report the new engineer and have their credentials yanked.
We don’t have that in software engineering. And outside of critical software we don’t need it. When the audio fucks up in Teams and you have to leave and re-enter the meeting, people don’t die.
Fuck Teams. The buggiest, most crash prone mess I’ve even been forced to use. They keep bolting on new, unnecessary “features” that only selectively work on some of their “supported” platforms.
I had a co-worker who was writing remote control software for a baseball-throwing machine. Not exactly “critical software” but he ended up firing a 125 mph knuckleball a foot above a 10-year-old kid’s head.
Counterpoint: tHe ShArEhOlDeRs SaY jUsT sHiP iT
Yeah ultimately CivEs get to withhold a signature and if they don’t sign it’s illegal to build. Software doesn’t need a PE
I’ve always been uncomfortable, honestly, with calling software developers “engineers”. Partly that’s because it’s actually illegal to call a non-PEng role an “engineer” in some jurisdictions (most of Canada), but I think this comment is an excellent point of distinction to make between PEng and other roles.
Legal responsibility along with regulatory requirements. There’s a reason everyone* trusts elevators and airplanes but shouldn’t trust most software.
I don’t know those guys so they can say what they want. We don’t just ship. We code, review, test and only then deploy. I will build this the only way I can see and it’ll take 3 days. Want me to start this?
Too late. They already outsourced it to someone who promised to get it done in one day for half the price.
Of course, it will take six months to fix all the problems it causes, but that is next quarter’s problem.
Lol, who outsources 1 piece of work like that. Never seen it done. Onboarding and exposure of code to outside world are big risks.
The difference there is that our project manager guy is afraid they’re gonna go to prison if they don’t let you add those supports and something goes wrong. But for the software dude, building things properly is unfortunately mostly a concern for you and the other software engineers, and mr project manager doesn’t have that much of an incentive to let you do that
I find project managers don’t want to be responsible for building shit that is flaky on prod. Either the consultancy reputation or team reputation becomes mud and their promotion opportunities vanish.
Yes that is probably the case for project managers that are actually held accountable
Then if you trust your team, have dev meetings and don’t give alternatives. Make it clear there is one way to do it and it’ll take x days long.
A good project manager understands technical debt.
Edit: moderately good
yeah but when I do that, people get mad at me and ask “why number so big”, then when I explain they say “ok but what if there aren’t any issues” and then they make schedules based on that clearly incorrect number
Mad? In a professional workplace?
“If you can give me that issue free codebase, I’m happy to do that, but failing that, it takes 3 days to add that feature that is akin to the leaning tower of Piza taped together with duct tape. There is only so much tech debt you can pile on until you are in code hell, and unfortunately, we are.”
If they do some weird ass schedule “well, you can write down that if you wish, feel free to write down that my other car is a Bugatti, if we are just theorising on a perfect unicorn world”.