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.”
