Ticket-Driven Development: The Fastest Way to Go Nowhere | Hacker News Reader

Ticket-Driven Development: The Fastest Way to Go Nowhere

thecynical.dev

50 pointsEdwardDiego42 comments

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.

> I didn’t meet the first full-time designer in my career until 2013.

You mean a UI designer?

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.

Because this was written by an LLM

That too…

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.

lol I was an English major

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.

I’ve found engineers, those that care about front end design anyway, to be better UX designers than supposed UX designers. Which makes sense as you’re integrating the design into an overall system and need to understand the implications in a deep way. Most UX designers can’t seem to think past the screen in front of them or even visualize anything but the narrow happy path. Unfortunately we’re training new engineers into this stupid corporate hierarchy where all decision making is taken away from engineers. I had to push junior engineers to speak up when they saw something as every signal to them is to stay on your lane.

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

Absolutely. Graphic designer != UX professional. A background in graphic design is often negatively correlated with making logical and ease to use interfaces.

Every place I've worked at in my 30 year career has had product managers in practice. They rarely had that as their title. The most common title for that role has been "CEO", since I've mostly worked in small companies. Some have had extensive engineering experience, some didn't. Some were actually working on the product, some weren't.

The best had a good rapport with both customers and engineers. Engineering experience helped gain this, but I've seen good ones without a lot of engineering experience. But I've never seen a good one without any engineering experience.

The problem isn’t that a single CEO exists who is ultimately making the final decision.

The problem is when companies try to create scores of “mini CEOs” (this is actually how PMs were explained when they started popping up) to oversee every aspect of every product.

A CEO of any but the smallest companies will have many other responsibilities, so they’ll have no choice but to delegate the majority of the decision making to the people actually building the product.

A PM running the search feature or the user onboarding experience or the notification system doesn’t have this limitation.

Also don’t get me wrong, I’ve worked with some fantastic PMs, but they were fantastic despite the role not because of it. Every good PM I’ve ever worked with had the capacity to be a good engineer even if they didn’t have the experience.

I've worked with bad PM's who were good engineers and good PM's who were mediocre engineers.

I had been very lucky in having a lot of say in design in my career. I worked with great designers who listened and could adapt their designs from feedback. That is until the last five years working at a larger tech company, especially the last three with this BS corporate layoff pressure. This is when I started getting side eye for pushing back on the design team for ignoring standard HID guidelines. I’ve seen some of the worst design output out of these folks. Like they gave zero thought to the general navigation or anything but the happy path. Issues one can identify in seconds from reviewing the design. And the politics are strong where people think you have no right to step outside your little engineering bubble and question these things. Of course that didn’t stop product owners and designers from stepping into your engineering bubble and trashing the place.

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.

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

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

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.

There’s also little job security and poor benefits.

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

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.

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.

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.

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.

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

Dunno man, it doesn’t have a pointless “conclusions” section - llms always do that.

My high school English teachers would be so happy.

Are you saying this was written by an LLM? Can you give examples for your assertion?

It's so obvious mate, the Velocity is Not Progress section is the worst.

Frequent bullet lists. Bolded key phrases. Varying sentence length for emphasis. “Not X, Y” phrasing structure. Pervasive second-person perspective.

I mean it’s possible somebody just writes like that, but I wouldn’t bet money on it.

The cadence and sentence structure is very obvious; GPT-based LLMs somehow just tend to be very haughty by default. There's the very slogan-esque 'X? Verb-in-past-tense. Y? Another-verb-in-past-tense' sort of sentences that're a dead give-away that something is written by an LLM. Also weird similes and constructions that make grammatical and even contextual sense, but don't really exist in English.

I'm intrigued, as this article did not trigger my (clearly as yet underdeveloped) GenAI spidey sense. Will you share some specifics of what triggered yours?

Separately, do you have any thoughts on the subject matter? Whoever or whatever put these words in a row, they resonate deeply with my lived experience of the last several years.

The brown comic image is a dead giveway too, does anyone know why so many of these have this weird pastel / brown color? I mean it fits with the theme of the page so it might just be confirmation bias or chance (that is, I don't notice the AI generated comics that aren't brown).

Alternative: the author actually wrote the words (because that's their opinion, and they want to share it to the world) and generated the comic with AI (as it's just a way to illustrate, and they're less proficient with drawing than with writing.)

I dabbled in writing, I would have hated for random people to assume my posts where AI generated, especially given that such a claim is practically unfalsifiable at this point.

(Comment guaranteed 100% human generated.)

One theory is it is the feedback from all the Ghibli stuff that went on a few months back. These tones first started appearing there for skin tone or even sky, then started appearing everywhere.

I think it's just the bland "thought leader" LinkedIn-style post - I don't think it's LLM-specific, but rather lowest common denominator writing that's very easy to write and reproduce and therefore easy to mimic with your favourite LLM.

EDIT: Although with just how generic the advice here is, and the ChatGPT images, this feels like a particularly egregious example of just dumping out LLM-generated content.

Plausibly correct...but humans were writing drivel to various subject and style spec's back when the CEO's official title was "Pharaoh". And any 2000's-era web designer learned that the client's actual content was often a downgrade from Lorem ipsum.

So "LLM-written" works as an insult, but it doesn't seem useful as a category for written works.

Can you expand on what about this article leads you to think that?

Reply on news.ycombinator.com