[motorest]

> There are probably going to be at least 3 public companies that should have "just" been GitHub features: GitLab (GitHub Enterprise), Sourcegraph (search), and Linear (GitHub Issues).

I don't agree, and I cannot understand what train of thought would lead to conclude that each individual feature that's a crucial part of any developer's workflow should be broken down to external companies without any good reason at all.

Any developer's workflow consists of a) ticketing, b) revision control, c) auditing code and change history, d) CICD. Obviously a) b) and c) are tightly coupled and you cannot have one without the other, whereas d) invariably leads to a) b) and c) in any incident response scenario. There is no argument that justifies any alternative to a unified developer experience.

[antics]

Sorry if this was not clear, but I am not making a normative statement that each feature should be broken out into its own tool. I'm saying that the revenue ramp on each these products is, empirically, good enough to be on track to IPO. So GitHub is apparently doing a bad enough job in each of those areas that three separate companies were able to break a feature out into a dedicated product, sell it on its own, and ramp revenue fast enough to support a venture class business. Absolutely wild stuff.

[cratermoon]

I feel like ticketing is something that has been pasted on for corporate reasons. Keeping track of the work to be done doesn't require a ticketing system, anyone remember using Story Cards? A whiteboard?

[TeMPOraL]

Well, if they wanted to implement keeping track of work to be done, they'd have long ago implemented subissues, sub-subissues, and sub^n-issues, because obviously work does not break down into a list, or a one-level-deep tree - the natural data structure for breaking down work is a directed graph (and if you really must do an 80/20 on it, then a tree).

Sadly, to this day, out of popular software packages used in software companies, only Microsoft Project and maybe Jira get this right. Unfortunately, they have plethora of unrelated issues that are big enough that they drive the industry towards silliness of managing work in tools like Trello or Github/Gitlab issues.

EDIT: I sometimes wonder how much of how Agile implementations look is a consequence of simplistic tooling. When your team's work planner is fundamentally unable to represent the basic idea that tasks can depend on other tasks, you can't really plan ahead much further than a sprint. So is the Agile cadence really about avoiding the Folly of the Waterfall, or is it just shitty tooling that makes it exponentially hard to think ahead for more than two weeks? Did we invent "epics" because we can't link together multiple tasks on a Kanban board?

And then, how many companies SCRUM the living hell out of their developers, while PMs secretly plan the whole thing ahead in MS Project to keep the project on track towards some goal, and then pray no one on the dev team spots a Gantt chart open on their screen?

(Personally, I worked under one once; they begrudgingly admitted to managing everything in MS Project once I started asking if I can get a license, because even Emacs Org Mode sucks at the job if the job is to break down month's worth of work on entire deliverable.)

EDIT2:

> Keeping track of the work to be done doesn't require a ticketing system, anyone remember using Story Cards? A whiteboard?

Anyone remembers a project plan? Work breakdown structure? I know PERT looks to people like a Borg Cube, but then the status quo in software dev looks like Pakled technology. "We are devs. We scrum. Trello make us go!"

[harrall]

I wouldn’t say Jira gets it right.

I find its subtasks a little half baked and I feel like portions of Jira weren’t designed with sub-tasks in mind. We actually avoid them completely at my current work.

It’s understandable why a lot of systems don’t support sub-tasks. Hierarchical data structures are not the easiest to deal with and come with a litany of edge cases. It can also be quite overwhelming UX wise.

[TeMPOraL]

> I feel like portions of Jira weren’t designed with sub-tasks in mind

That's true, and I can see why you avoid them. Last time I touched Jira, I quickly learned that subtasks are annoying.

Dependency releationships between tasks are more general and better overall. Unfortunately,

> Hierarchical data structures are not the easiest to deal with and come with a litany of edge cases. It can also be quite overwhelming UX wise.

Don't know of any software that fully figured it out. Even MS Project, which does the relationship and scheduling parts a-ok, is a PITA to use in general, and has some pretty annoying bugs that made me stop using it. Being able to irrecoverably brick the auto-scheduler and have it suddenly crash on opening the project file is a kind of show-stopper.

Another tricky challenge here is scope. Planning, scheduling and doing are three different mindsets, and it's tough to balance them all in a single tool. Someone who figures out how to do it well stands to make a lot of money.

[cratermoon]

> I sometimes wonder how much of how Agile implementations look is a consequence of simplistic tooling. When your team's work planner is fundamentally unable to represent the basic idea that tasks can depend on other tasks

In the agile world it's accepted that a task that today looks like it depends on another task may not have that dependency next week. Planning involves scheduling what the stakeholders prioritize now that can be done, and whatever lands in the "we can't do that until we do other thing" doesn't even get scheduled.

[TeMPOraL]

> Planning involves scheduling what the stakeholders prioritize now that can be done, and whatever lands in the "we can't do that until we do other thing" doesn't even get scheduled.

Planning and scheduling/prioritizing are two distinct processes people often confuse. Planning is about identifying what needs to be done, and breaking it down into a network of tasks joined by dependencies. Scheduling is figuring out who's going to do what and when they're going to do it.

Planning is figuring out your service needs e-mail verification, password reset, and some transactional messages, to stuff like "design e-mail templates" "write templates for {verification, reset, account confirmation} e-mails", "set up infra for sending e-mails", "add {verification, reset} URL flows", "make it send {verification, reset, confirmation} e-mail on {{relevant action}}", etc. Scheduling is me assigning "design e-mail templates" to Joe in graphics dept. and giving him 3 days for it, assigning you the "set up infra" task and giving you a week, and knowing the "make it send ..." tasks won't start until next sprint, at which point we'll find someone to do them, etc.

In naive Agile reality, while <<whatever lands in the "we can't do that until we do other thing" doesn't even get scheduled>>, it gets recorded somewhere (e.g. product backlog), but it won't have its dependency relationship encoded. So every sprint, someone goes over a heap of such tasks, and has to manually reconstruct those relationships, to the degree it lets them plan out the next sprint or two. This both adds work and limits the ability to plan forward (you ain't going to be even thinking about stuff that's obviously beyond the horizon).

While it's true that stakeholder priorities change (as they should), and this affects scheduling, it affects planning much less, as the dependencies aren't about order in time, they're about order in execution. Dependencies aren't volatile - no matter what the stakeholders think this week, you won't be able to work on "make it send emails" until you can send e-mails (infra task) and have e-mails to send (design/write) and have them be useful (endpoints/routes for links). This is useful information to have encoded, particularly with more interdependent features - not only the system will help you do the scheduling correctly, it'll also let you quickly tell that unscheduling work on X now will delay work on Y down the line, etc.

[cratermoon]

Planning and scheduling/prioritizing are split into separate things by people who think less about shipping working code and more about counting beans.

[TeMPOraL]

Shipping working code is a means to an end, not end unto itself. Planning and scheduling/prioritizing are split into separate things by people who think about and then tell the people shipping working code what they should be writing and shipping.

[ImPostingOnHN]

I hate bureaucracy and will actively question the necessity of any imposition of bureaucracy, and resist its imposition if it doesn't seem justified.

Nonetheless, there is use to more than just sticky notes. It tends to come with scale, and trying to coordinate and align teams of teams of teams of teams, etc.

Additionally, sticky notes are impractical for remote teams (would there be some always-on webcam pointed at them?)