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.”
“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”.
I feel like every retro I’ve attended has been a farce.
“What went bad? We said doing it this way would be harder and more risk prone. Management insisted we do it that way, and it took longer than and caused a site outage.”
Delayed response, but raise a ticket in retros saying retros should be cancelled. Andvwhrn asked why, say nothing is followed upon or learn so there is no point doing them.
Then you can talk shit about them and make clear without change, you won’t commit time to next one as there is no point.
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.”
My current boss: so I sold this at least 10% below budget and we have to make it work.
Fuck that guy!
Reality is already fucking him sideways but he keeps escaping reality. He’s like a financial Houdini.
Just build and deploy it! We have the shareholders to think of!
“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”.
I feel like every retro I’ve attended has been a farce.
“What went bad? We said doing it this way would be harder and more risk prone. Management insisted we do it that way, and it took longer than and caused a site outage.”
"What should we do differently?’
“Listen to the team next time”
“That won’t happen”
Delayed response, but raise a ticket in retros saying retros should be cancelled. Andvwhrn asked why, say nothing is followed upon or learn so there is no point doing them.
Then you can talk shit about them and make clear without change, you won’t commit time to next one as there is no point.
Could be fun to see what the response is.