51–60 of 61 posts
This is nagging, visible, and taunts you as long as you haven't done the thing "to do", as opposed to "TODO" comments that become invisible at some point.
You can use flags to run the code to raise exceptions for any warning and you basically have your sprint laid out for you.
I wish there was a way to leave a comment like // todo(gravypod, techdebt): some description of the issue and have that, when pushed up to a VCS, turn into an issue created, assigned to me, and labeled with tech debt. I know this exists in some of the walled gardens like Google's internal infrastructure but I think if this existed in the open world you'd see a lot more consistency between issues/comments and you'd en…
Earlier quoted context omitted.
I've already built a little tooling around pull requests and git commits at autodesk and so when I read this, I thought, oh, yeah, that's a great idea, I should do that. But here's the thing. Our team already has a policy for TODOs: either you open a ticket and leave the ticket number in the code, or you do not leave a todo at all. This way, we're never guessing which ticket belong to which todo, and all of the neces…
> It increases the barrier to entry if you are going to leave a TODO (versus leaving it out or just not being lazy and doing it), and prevents the backlog from needing even more grooming I would rather have many tickets that specify actual work than a lot of work specified in no tickets. Using monotony as a filter doesn't sound like it would lower defect rates over long periods of time.
Yes, it's tedium. But it's necessary tedium. It's documentation.
Earlier quoted context omitted.
It’s really hard to convey tech debt cost . Probably many systems have a ton of problems adding 5% to every feature here, 10% there, bad DB design from early in the project that makes a bunch of actions far riskier than they should be (but until it breaks several times no-one cares and if your devs are putting 3x as much effort into those dangerous operations and know what they’re doing, it won’t), and so on. Communi…
Never ask permission to do what has to be done. If they say no, and you do it anyway, then you are being insubordinate. If you don’t do it and then point to the decision as a reason why the project is failing, then you are right, but are a failure.
I personally force stakeholders to define sunset dates on the system / code ill be writing.
If its sunset date is never, cost of development proportional to roi approaches zero.
If the sunset date is near, cost of development gets very, very expensive.
Having that information both informs my priorities and the understanding of how long development will take / cost.
Earlier quoted context omitted.
In practice this results in too much time spent “cleaning up” and not enough time delivering business value. Hence why tech debt tickets are valuable, they allow the business to decide when to spend time on them.
The business can and should set a general tone about where it wants to sit on the sloppy vs. perfectionist spectrum, but it's not competent to make those decisions at a granular level. That requires engineering sensibilities. We have a small but dedicated percentage of sprint bandwidth dedicated to engineering's internal priorities, off limits to PMs. It works decently well. Certainly better than letting PMs make cal…
I do something like this approach too - Friday mornings I try to start with devops / tech debt / hacking instead of product priorities.
Earlier quoted context omitted.
Never ask permission to do what has to be done. If they say no, and you do it anyway, then you are being insubordinate. If you don’t do it and then point to the decision as a reason why the project is failing, then you are right, but are a failure.
And if you take too long to ship you're still a failure. I personally force stakeholders to define sunset dates on the system / code ill be writing. If its sunset date is never, cost of development proportional to roi approaches zero. If the sunset date is near, cost of development gets very, very expensive. Having that information both informs my priorities and the understanding of how long development will take / c…
I am not sure that is good economics, because the discount rate for the future revenue approaches 100% over extended time.
Earlier quoted context omitted.
The business can and should set a general tone about where it wants to sit on the sloppy vs. perfectionist spectrum, but it's not competent to make those decisions at a granular level. That requires engineering sensibilities. We have a small but dedicated percentage of sprint bandwidth dedicated to engineering's internal priorities, off limits to PMs. It works decently well. Certainly better than letting PMs make cal…
Out of curiosity, what's the percentage? I do something like this approach too - Friday mornings I try to start with devops / tech debt / hacking instead of product priorities.
Earlier quoted context omitted.
I've always wondered about other people's experiences with backlogs. In all of the client accounts I've been to, a backlog was at the end of the day, simply leadership acknowledgement that there exists more work to do than there is budget to do it, and the backlog really should be mostly the last stage of an issue triage. I wonder if any organizations would benefit from the effort to maintain an officially-recognized…
I completely agree with what you said. But tech debt, at least for me, feels very different from the tasks that should be triaged. It's very uncommon that we allocate time to repay certain debt, so does it make sense to triage and/or backlog? That was mainly my point with previous comment. My experience is more like doing some other task, coming across some tech debt, and repaying it on the spot if I'm not that const…
Backlogs I've seen have tended to evolve into a graveyard of wish list items. But there is rarely even an attempt at quantifying the organizational cost of putting off tackling the debt until it ties into some obvious, acute measure that usually is some capex, typically software licensing, or some really way off opex, like hundreds of operations staff manually addressing issues that could be automated.
I'm wondering with so many organizations now tracking software engineering effort at a relatively granular level now with various degrees of agile projects, whether or not I could leverage the mere fact that we're seeing the effort listed out now.
Example: my team has a bunch of servers all mounting an NFS file share. Neither the OS or NAS teams ensure the mounts stay up. For a few years before I arrived, the mounts across the landscape just deteriorate, handled by individual support tickets until the degradation becomes too large to ignore, and then a task is tacked onto the current sprint for some poor schmoe to log into each server and ensure the mount works.
A quick scan of the incident tickets and the historical tasks gave me a defensible estimate of an average of 50 man-hours per year spent on this issue alone, not even counting any meetings to discuss it with customers.
In the real world, I had to use my personal Emacs Org mode agenda to keep attempting (until I succeeded) to add a task to an upcoming sprint to put in requests to automate monitoring, mounting, and alerting the OS and NAS teams when the mount fails. In "systematic technical debt management" world, when I see the incident pattern I would create a backlog task. The backlog item sinks to the graveyard/tech debt status, and every time a new incident or task comes up that would not if we resolve that debt, the time it takes to address the incident or task gets added to the debt.
The problem I'm wrestling with implementing such a mechanism is it relies upon people to remember and care about the debt in the first place, to associate it with a current work effort. That doesn't work in my experience; it's hard enough to get people to share what they are working on in such ticketing systems in the first place.
Earlier quoted context omitted.
That's neat. I never knew this existed. Unfortunately I mainly use Gitlab wherever I work.
There's an issue for this in GitLab's tracker: https://gitlab.com/gitlab-org/gitlab/-/issues/14259 Sadly, it's four years old and seems pretty stagnant.
https://gitlab.com/gitlab-org/gitlab/-/issues/14259#note_327...