5 ms·

Ticket-Driven Development: The Fastest Way to Go Nowhere

50 points by EdwardDiego 1y ago

breckenedge 1y ago
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.
- koakuma-chan 1y ago
  > I didn’t meet the first full-time designer in my career until 2013. You mean a UI designer?
- hansmayer 1y ago
  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.
- Cheer2171 1y ago
  Because this was written by an LLM
  - breckenedge 1y ago
    That too…
- jonstewart 1y ago
  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.
  - breckenedge 1y ago
    lol I was an English major
- sarchertech 1y ago
  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.
  - spacemadness 1y ago
    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.
- bryanlarsen 1y ago
  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.
  - sarchertech 1y ago
    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.
    - bryanlarsen 1y ago
      I've worked with bad PM's who were good engineers and good PM's who were mediocre engineers.
- spacemadness 1y ago
  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.
comrade1234 1y ago
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 1y ago
  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.
deleted 1y ago
[deleted]
cowbolt 1y ago
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).
- loloquwowndueo 1y ago
  Dunno man, it doesn’t have a pointless “conclusions” section - llms always do that.
  - mikepurvis 1y ago
    My high school English teachers would be so happy.
- smartmic 1y ago
  Are you saying this was written by an LLM? Can you give examples for your assertion?
  - Cheer2171 1y ago
    It's so obvious mate, the Velocity is Not Progress section is the worst.
  - twoodfin 1y ago
    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.
    - delta_p_delta_x 1y ago
      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.
the_real_cher 1y ago
I wonder how content aggregators like HN are going to deal with the tidal wave of AI slop that's coming.
- Cthulhu_ 1y ago
  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 1y ago
    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.
dikei 1y ago
I hate ticket-driven development, but clearing ticket is one way to stay sane when the final objective looks crazily out-of-touch.
hansmayer 1y ago
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)
baalimago 1y ago
If you don't like it, maybe swap jobs. As a tip: There's very little time for ticket driven development in startups.
- azemetre 1y ago
  There’s also little job security and poor benefits.
roxolotl 1y ago
> 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.
deleted 1y ago
[deleted]
emacsen 1y ago
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 1y ago
  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.
theturtle 1y ago
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.
emushack 1y ago
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.

50 points by EdwardDiego 1y ago

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.

koakuma-chan 1y ago
> I didn’t meet the first full-time designer in my career until 2013. You mean a UI designer?
hansmayer 1y ago
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.
Cheer2171 1y ago
Because this was written by an LLM
- breckenedge 1y ago
  That too…
jonstewart 1y ago
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.
- breckenedge 1y ago
  lol I was an English major
sarchertech 1y ago
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.
- spacemadness 1y ago
  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.
bryanlarsen 1y ago
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.
- sarchertech 1y ago
  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.
  - bryanlarsen 1y ago
    I've worked with bad PM's who were good engineers and good PM's who were mediocre engineers.
spacemadness 1y ago
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.

comrade1234 1y ago

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 1y ago
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.

deleted 1y ago

[deleted]

cowbolt 1y ago

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

loloquwowndueo 1y ago
Dunno man, it doesn’t have a pointless “conclusions” section - llms always do that.
- mikepurvis 1y ago
  My high school English teachers would be so happy.
smartmic 1y ago
Are you saying this was written by an LLM? Can you give examples for your assertion?
- Cheer2171 1y ago
  It's so obvious mate, the Velocity is Not Progress section is the worst.
- twoodfin 1y ago
  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.
  - delta_p_delta_x 1y ago
    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.

the_real_cher 1y ago

I wonder how content aggregators like HN are going to deal with the tidal wave of AI slop that's coming.

Cthulhu_ 1y ago
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 1y ago
  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.

dikei 1y ago

I hate ticket-driven development, but clearing ticket is one way to stay sane when the final objective looks crazily out-of-touch.

hansmayer 1y ago

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)

baalimago 1y ago

If you don't like it, maybe swap jobs. As a tip: There's very little time for ticket driven development in startups.

azemetre 1y ago
There’s also little job security and poor benefits.

roxolotl 1y ago

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

deleted 1y ago

[deleted]

emacsen 1y ago

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 1y ago
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.

theturtle 1y ago

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.

emushack 1y ago

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.