[swagonomixxx]

> But all technology evolves, and git is already showing its weaknesses. Fork-and-pull isn't the final form of development workflows.

I kind of get what this is saying, but technology evolution doesn't have to mean completely replacing said technology with something else.

I think that's one weird thing about the software field, whereby we keep moving to these shiny new things that we think are better than the tools of yesteryear, yet in the end there is only a marginal gain in productivity.

Fork and pull is an incredibly productive and powerful workflow. CI is incredibly, incredibly useful. If these things were not the case, then neither of these would be even discussed by this article. There is a reason for their success - and it's not because GitHub is the most ubiquitous code hosting service out there. Git is _actually_ pretty great. CI is _actually_ very useful and has secured codebases for decades at this point.

So if one were to proclaim the "End of CI" I really need to see a viable alternative that addresses the same problems as CI and significantly improves upon it. An incremental improvement is not enough to shift and rewrite everything - there needs to be a significant jump in ability, productivity, security, or something else in order for me (and I imagine many others) to consider it.

[andyjohnson0]

> I think that's one weird thing about the software field, whereby we keep moving to these shiny new things that we think are better than the tools of yesteryear, yet in the end there is only a marginal gain in productivity.

"Thought leaders" need to he constantly talking up the next new thing so that they can stay ahead of the herd on socia media.

Developers get bored, or worry that their career is stagnating, if they're not using the new shiny. Particularly if they pay attention to the thought leaders, or they're stuck building unglamorous crud apps.

And the software industry generally has a poor collective memory of tools and practices and experience from even the recent past. Contrast with more mature engineering disciplines, or architecture, medicine, etc. I'm not sure why this is.

[b3morales]

I do think there's a bit of a visibility bias here, though: plenty of us know that there's money and stability to be had with deeply competent knowledge of the "old" stuff. We just don't make weekly posts on $MEDIA about it.

[chiefalchemist]

> I think that's one weird thing about the software field, whereby we keep moving to these shiny new things that we think are better than the tools of yesteryear, yet in the end there is only a marginal gain in productivity.

Agreed. But I'd take it a step further and say:

...yet in the end no one is any happier. Not engineers. Not management. Not leadership. And most importantly not the users of the product.

We keep building and delivering more. But how often is that better? Either as an end to end experience or simply fewer bugs? Most of us - who are at some point users of products we didn't build - have resigned ourselves to that fact (read: it's been normalized) that an uncomfortable amount of friction is a given. That's sad.

[ip26]

There’s always problems and always friction. The new shiny doesn’t always help. But I do feel happier when I am able to move to the next level of problem. To spend my time wrestling with more meaningful challenges and less trivialities. Better tooling can help with that, although to make it a reality your org needs to see “increase quality” as the first step in “delivering more”

[chiefalchemist]

To restate my point with brevity: More efficient doesn't mean more effective.

FFS, look at GitHub. Shows your commits. They could be a high percentage of shite yet we drool over a saturated commit graph.

[astrobe_]

> Either as an end to end experience or simply fewer bugs?

I'd say we build bigger things with the same size/bug ratio. Therefore, "Small is beautiful".

[chiefalchemist]

Maybe. But user's have no sense of size. Nor do that care.

I am forever fielding questions / issue from my (retirement age+) parents. They are my benchmark for usability. From being able to open jars of food, to a website bug, to ambiguous UXs.

Until these questions are reduced - and they been steady for many year now - then I'll presume we, the makers, are failing.

[astrobe_]

> Nor do that care.

That's a misunderstanding about size. It is not about saving some kilobytes - indeed we have more than enough RAM/ROM/flash/mass storage in general, although it is a bit less true currently due to shortages - but it is a hint that the whole thing is better in other areas as well.

Except for the cases where a speed/size trade-off has been made of course. But even when it is a features/size trade-off, it is not always a bad deal, because software often has lots of features you don't care about, but could nevertheless introduce bugs in the features you do use.

[jt2190]

What the author should have made more clear is that we’re starting to see technology that eliminates the “local developer environment” completely, and we’re also starting to see collaborative real-time code editors. Taken together, we can imagine a world where a dev points their browser at codebase hosted somewhere and just starts editing. Each edit is a change event that the system reacts to by running compilers, then unit tests, etc. and provides near real-time feedback that the code works/doesn’t work, right in the editor. In this world the developer does not push their changes, the system does that for them, while they’re working. The CI server disappears from view completely.

[swagonomixxx]

That's an interesting take that I didn't think of. I think the burden on having a cloud-based development environment on ops teams will be non-zero though - some set of individuals (or a dedicated team) will have to maintain these very beefy hosts of your code that run the tests for you.

That said, I'm not against the idea in principle if access to the internet is guaranteed and constant. In some places that I'm in, internet access is shoddy or just too slow for this kind of thing, and my preference there would be to work easily on a local machine without access to the internet.

[neatze]

> I kind of get what this is saying, but technology evolution doesn't have to mean completely replacing said technology with something else.

Technology and in general historical trends are rarely broken, they change but there is no gaps in sense, I don't remember who said it, someone in defense R&D, if recall correctly.

[oldjavacoder]

"Fork-and-pull isn't the final form of development workflows."

Actually, like the wheel, I think it is the final form. When artificially sentient machines are writing code for us and someone or some thing pollutes or corrupts a critical model; a human will need so step in and fork where things were working to fix it.