You must log in or # to comment.
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.
More like: you know when you get home after a long day and you just toss your clothes wherever, then when you wash them you just toss the clean clothes on your bed rather than putting them away properly because ‘i know which ones are clean’?
Tech debt is all the minutes you spend in the morning and each week on laundry day, sniffing stuff to see if it needs to be washed, and the massive organizational task you’ll have to do if you ever buy lots more clothes or think you might bring company to bed or ever have to move to a new place.
Or: ‘tech debt is at home in the mirror. That is its address.’ ‘yeah I hate kids.’
This seems more like an example of procrastination not technical debt. Technical debt as I understand it requires a previous decision to impeed new decisions/progress because it wasn’t done properly the first time.
A better example would be he wants to add a brick chimney to the roof but can’t because the roof is made of straw thatch and can’t support the weight, so it would need to be rebuilt first out of timber, and then a chimmney can be added.
translate from french
Outstanding.
This reminds me of some issues in my relationship. Some problems that never gets solved.
I highly recommend solving the important ones and learning to let the rest go, speaking as someone whose marriage just exploded over exactly that.
This is an explanation on why it never gets fixed.
The technical debt would be the additional damage being done to the rest of the house each time it rains.
Shall we renovate?
Yeah sure, just spend 4 x more to carefully work around the roof hole! Install waterproof furniture! Give out umbrellas to guests!
