> Either way, you didn’t write it, you didn’t scope it, and you definitely didn’t question it.
Ok sure maybe you didn’t write it, but if the team working on the tickets don’t scope and question them you’re doing it wrong. Of course things are going to turn out badly.
I was once told by "the architect", and I quote, "put blinders on. I will tell you when to take them off.". The context was I was asking about the why.
Looking back on it, yeah it absolutely felt like I was being told to stop thinking.
In my experience it works fine for a large geographically dispersed team.
There was a project that I was on that did get a little ridiculous. It was a major German airline and we were redoing their website (front and back). Team was in three countries including India. Maybe 25 developers? We had a spec document that we had to code to, including the front-end wireframes. If there was an obvious mistake in the spec, like a misspelling for a button, we still had to code to the spec along with the misspelling and then file a bug against the spec. They fix the misspelling in the spec and now there's a bug in the website...
So a bit more flexibility than that and the project would have been great.
I hate ticket-driven development, but clearing ticket is one way to stay sane when the final objective looks crazily out-of-touch.
If you don't like it, maybe swap jobs. As a tip: There's very little time for ticket driven development in startups.
The authors main premise and diagnosis is spot-on, the solution? Not so much - unless you want to encourage the system to stay in place, because, hey - the software seems to get better every week (at the expense of devs)
As a new boss who has recently started using Story Points and requiring the devs stick to tickets, I think this article points to problems that are valid, but unrelated to the issue of tickets.
> a factory that forgot what it’s building. Features ship, bugs creep back in, and the codebase becomes an archaeological dig of short-term fixes and forgotten context.
That's tangential to tickets.
We always had tickets to some extent, but our current process involves organized feature planning, design tickets, implementation tickets, and review.
That has imposed a lot more structure, but it's also resulted in a lot less work. Developers know what the priorities are, know what the scope of work is, they know they'll get reviewed.
Issues the article talks about such as short term technical debt being accepted are tangential. If a problem comes up, it's documented and then a decision is made on when to address it. If it's serious, that could be immediately, and if not, it may be put aside until it's encapsulated in other work, such as a refactor or redesign.
Tickets drastically improve context by telling the story of what they're about, connecting to commits, and connecting to merge requests. The code becomes a series of narratives.
> “Yeah, good thought, but just stick to the ticket for now.”
That's bad management. Good management will say "Good thought, make a new ticket for it so we can hear what's on your mind and evaluate it."
> Ask why the feature matters? You’re overstepping.
Ask why the feature matters and you're a good dev!
But before we had this level of structure at my organization, sometimes the devs would override the stakeholder's explicit wishes without informing them!
Now with tickets there's an opportunity for dialog and a paper trail on decisions.
> Suggest a refactor while in the code? Not in scope.
This one is tricky as I just told a dev not to do a refactor this week. The reason was the refactor was tangential to the feature, which was already late to deliver. Instead, a ticket was made and we'll evaluate the decision to refactor next week.
> Improve naming, extract duplication, or add a helpful comment? That’s gold plating now.
Those aren't gold plating, they're part of code quality checks that go into reviews.
The tickets aren't the issue here any more than one might complain about a specific programming language being the problem. The core issue is the environment, and specifically of management. Before I had tickets, developers worked on what they wanted to work on
Support invented this particular form of enshittification decades ago; sorta sucks to see it on the dev side.
In support, most of the time "solving the actual problem" is irrelevant, and "closing the ticket" is paramount.
I wonder how content aggregators like HN are going to deal with the tidal wave of AI slop that's coming.
It's interesting how easy it is to spot LLM-written text after you familiarize yourself with its general writing style (at least for the GPT-based models).
How can you write an article about this and not mention that software development used to be radically different and better?
I didn’t meet the first full-time designer in my career until 2013. If there were designers around, it wasn’t their only role or they were mostly contract. Before that, developers were intricately involved with the design process. It maybe wasn’t as pretty but it sure wasn’t was buggy.
And project planning used to be done by engineering leads. Now you have specialized PMs who really know nothing about engineering practices. Engineering managers were responsible for whole project plans. We lost a lot when we gave up that role —- there’s a lot more trust and collaboration between an engineer and an EM versus an engineer and PM.
I’ve liked my career less and less over the last 10 years or so because I’ve seen every company go this direction. I think companies do it to de-risk, but it makes the whole process more expensive.