Ticket-Driven Development: The Fastest Way to Go Nowhere
36 comments
·June 26, 2025breckenedge
hansmayer
Exactly this. I think we lost so much because we allowed people who dont know how to reduce brightness on their monitor to "own" anything in the software dev process. Now they are teaching us that engineering leads should "negotiate" with POs about technical improvements, and how we can best frame it. Excuse me, but what the f? What we call POs now, used to be Business Analysts - valuable contributors for sure, but not "owning" anything. And we made it a big point if an element is 2px farther to the right than the designer foresaw. Not to mention that the agilistas have managed to create cohorts of bootcamp-type-coders whose main concern now is a "well written ticket". Never thinking or heaven forbid, caring about the whole project. I am generally critical towards the enthusiastic usage of LLM tools, but I do think they will have a positive effect of a lot of people not belonging to tech, leaving it.
sarchertech
There used to be subject matter experts, and business analysts. Then companies combined those roles into PMs. I think the biggest problem with that is adding the name Manager to the title and allowing them to “own” the product as opposed to the way it originally worked where it was more collaborative and if anyone owned the product it was engineering.
When I took software engineering classes in school, talking to customers and subject matter experts and figuring out what they wanted was a core part of what we covered.
All these extra layers really are just an absurdity. You hit the nail on the head with your point about de-risking. It seems companies would rather hire 10x the people and spend 10x the money for a 75% chance at producing something mediocre than taking a shot at making something great.
To some extent you can go work for startups to reduce your exposure to this kind of environment, but these days any startup with more than 5 employees thinks they need a PM.
Don’t get me started on UX designers. I’ve taken rigorous HCI classes in grad school. It’s a real academic discipline with tons of theory behind it.
What most UX designers are doing now isn’t close to that. What happened is that number of print design jobs collapsed, and everyone who had a basic understanding of design principles decided to call themselves a UX/UI designer.
So now in many companies you have entire teams of PMs and designers who have next to no engineering understanding designing features and systems before anyone who actually knows how to build the thing even hears about it.
My long term plan is to find some small niche where performance, correctness, and reliability are highly valued and build something that a modern software factory or a VC backed startup with a move fast and break things attitude can’t compete with.
My suspicion is that what I’m looking for is a very small slice of the customer base of an existing very boring piece of business software.
jonstewart
Software development was better before computer science became the most popular major, because only people who loved programming could possibly stand the weird awfulness of CS classes. Now kids who’d’ve been business majors in the 90s are flooding our ranks. It’s a different thing.
koakuma-chan
> I didn’t meet the first full-time designer in my career until 2013.
You mean a UI designer?
roxolotl
> 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.
comrade1234
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.
bestouff
I'd say it works fine when you consider your dev team as cattle, not pets. It's the kubernetes of engineering management. So you don't really care who does what or if your team likes what they do, or if someone has articulated a clear vision of where you want to go, you just want tickets chugging.
emushack
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.
null
baalimago
If you don't like it, maybe swap jobs. As a tip: There's very little time for ticket driven development in startups.
hansmayer
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)
dikei
I hate ticket-driven development, but clearing ticket is one way to stay sane when the final objective looks crazily out-of-touch.
theturtle
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.
emacsen
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
billy99k
I've worked on projects without a structure like story points, and it's usually a complete mess. Developers love it because there isn't any real way to gauge individual progress, but business owners hate it because projects never get done on time and lots of money is wasted.
null
the_real_cher
I wonder how content aggregators like HN are going to deal with the tidal wave of AI slop that's coming.
Cthulhu_
Unless they install policies AND their communities are generally anti-AI-generated-content AND there's protections in place to prevent bots from upvoting... nothing.
Besides, aren't some of the biggest SF companies all about AI right now? Aren't the big investors, developers, and thought leaders in AI present on, if not owning this site?
As an individual, you can only downvote, comment, or leave; if it's really important to you, leaving is unfortunately the only choice and in all likelihood nobody will miss you / it won't have made a difference. But it'd be better for your own sanity.
the_real_cher
I disagree with this defeatist view because it underestimates the power of individual and collective action in shaping online communities. While it's true that large companies and AI proponents have influence, platforms ultimately depend on active, engaged users to thrive. Individuals who speak out, organize, and demand transparency and policy enforcement can create meaningful pressure — we've seen this happen across many platforms in the past. Dismissing user input as futile not only discourages healthy dissent, it also hands control entirely to those with the most capital, which is exactly what fosters stagnation and groupthink. Change may be slow, but resignation guarantees nothing ever improves.
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.