Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Where does engineering go? Retreat findings and insights [pdf]

thoughtworks.com

Post reply on HN
Print view View original

21–30 of 34 posts

Re: Where does engineering go? Retreat findings and insights [pdf]

#21

Post by Rapzid »

lelandbatey wrote: post #18
Rapzid wrote: post #8

Earlier quoted context omitted.

> "Where does the rigor go?" > Engineering quality doesn't disappear when AI writes code. It migrates to specs, tests, constraints, and risk management. These are generic "thoughts" you can get from any agency pushing AI SDLC. The pages I read through left me wondering if there was even a real retreat.

You're right that this isn't some groundbreaking revelation. If you're using AI enough to be feeling it, you're feeling/seeing what they're talking about. The purpose of a paper/retreat like this it get it all together and written down on paper, then to disseminate it to the wider world. I think the paper does a good job of collecting info that isn't wrong, and which has enough info to help guide folks making decisio…

It's drivel.

Re: Where does engineering go? Retreat findings and insights [pdf]

#22

Post by dang »

codethief wrote: post #20
dang wrote: post #4

Earlier quoted context omitted.

Ok, let's give it a try. (Btw, @dang doesn't work reliably - for that you need to email hn@ycombinator.com. I only saw this by accident.)

I think the original title is better than the current one, though: "The future of software engineering – [Thoughtworks] retreat findings and strategic insights"

Why do you think it is better?

Re: Where does engineering go? Retreat findings and insights [pdf]

#23

Post by voxleone »

>>Where does engineering go?

Up the abstraction ladder; we conceive axioms and constraints; we define actors and objects; we direct rules, flows, sequences and say when and how each one of them lives and dies.

May you live interesting times (some say this is a curse)

Re: Where does engineering go? Retreat findings and insights [pdf]

#24

Post by drivebyhooting »

Pasanpr wrote: post #19

> The product management side of this equation is equally unsettled. If developers are now thinking more about what to build and why, they are doing work that used to belong to product managers It's not clear to me why this is true. If LLMs are writing code, why are developers simply not orchestrating the completion of more features instead of moving up the stack to do product development work? Is there some implicat…

Because feature development speed wasn’t the bottleneck a lot of times.

Re: Where does engineering go? Retreat findings and insights [pdf]

#25

Post by roncesvalles »

Pasanpr wrote: post #19

> The product management side of this equation is equally unsettled. If developers are now thinking more about what to build and why, they are doing work that used to belong to product managers It's not clear to me why this is true. If LLMs are writing code, why are developers simply not orchestrating the completion of more features instead of moving up the stack to do product development work? Is there some implicat…

Arguably the PM role only exists because SWEs don't want to do PM work, and the industry acquiesced to this because SWEs are in very short supply - if you could hire a layperson (sorry) to take a few hours of non-technical work off a SWE's plate, it is worth it.

In a (hypothetical; not quite there yet) world where SWEs are in surplus, there is no reason to have PMs.

The really eye-popping efficiency gains from LLM coding won't come from doing the coding faster but from consolidating the PM, SWE, and QA/SDET roles under the same person. Then you'll start seeing startup/indie level productivity-per-person inside large organizations. Imagine Google is like 50,000 Pieter Levels.

Re: Where does engineering go? Retreat findings and insights [pdf]

#26

Post by wreath »

Pasanpr wrote: post #19

> The product management side of this equation is equally unsettled. If developers are now thinking more about what to build and why, they are doing work that used to belong to product managers It's not clear to me why this is true. If LLMs are writing code, why are developers simply not orchestrating the completion of more features instead of moving up the stack to do product development work? Is there some implicat…

PMs do different things in different organizations.

In my last job, PMs were responsible for identifying problems that were worth solving and align with the overall company vision and plans within the owned domain, and design+engineering decided how to solve those problems and what to build. Of course with collaboration w/ the PMs (and EMs).

The job before that, PMs wrote jira tickets and nagged engineering when tickets will be delivered. The "what problems to solve and what to build" questions came straight from CEO/CTO.

Re: Where does engineering go? Retreat findings and insights [pdf]

#27

Post by manphone »

roncesvalles wrote: post #25
Pasanpr wrote: post #19

> The product management side of this equation is equally unsettled. If developers are now thinking more about what to build and why, they are doing work that used to belong to product managers It's not clear to me why this is true. If LLMs are writing code, why are developers simply not orchestrating the completion of more features instead of moving up the stack to do product development work? Is there some implicat…

Arguably the PM role only exists because SWEs don't want to do PM work, and the industry acquiesced to this because SWEs are in very short supply - if you could hire a layperson (sorry) to take a few hours of non-technical work off a SWE's plate, it is worth it. In a (hypothetical; not quite there yet) world where SWEs are in surplus, there is no reason to have PMs. The really eye-popping efficiency gains from LLM co…

The concept of a large organization doesn’t even make sense in this model. How do you make decisions? How do you coordinate? What is Google when you have 50,000 individual silos?

Re: Where does engineering go? Retreat findings and insights [pdf]

#28

Post by bmurphy1976 »

kingkongjaffa wrote: post #7
bmurphy1976 wrote: post #3

@dang this is a very interesting and relevant doc. I think it needs another chance at making it to the front page. This is a fairly easy to read doc discussing some of the challenges with using AI tooling in a forward thinking and disciplined way. Coming from Thoughtworks it also gives a bit of gravitas and legitimacy. There's good stuff in here. It would be a shame for the larger HN community to miss out on this con…

> Coming from Thoughtworks it also gives a bit of gravitas Why? I thought the opposite. Consultancies, of which thoughtworks is one, publish thought leadership as marketing material.

Sigh. Nobody is ever going to be happy. Would saying it came from a rando Reddit user be better?

They at least put the effort into having the retreat and putting this together. Would other consultancies (who we know little about) have of done the same?

Re: Where does engineering go? Retreat findings and insights [pdf]

#29

Post by mbrumlow »

manphone wrote: post #27
roncesvalles wrote: post #25

Earlier quoted context omitted.

Arguably the PM role only exists because SWEs don't want to do PM work, and the industry acquiesced to this because SWEs are in very short supply - if you could hire a layperson (sorry) to take a few hours of non-technical work off a SWE's plate, it is worth it. In a (hypothetical; not quite there yet) world where SWEs are in surplus, there is no reason to have PMs. The really eye-popping efficiency gains from LLM co…

The concept of a large organization doesn’t even make sense in this model. How do you make decisions? How do you coordinate? What is Google when you have 50,000 individual silos?

Decisions are less costly. When a swe can take 4 days to do what would have cost 6 months, the math of making sure you are doing the right thing before executing goes away.

Re: Where does engineering go? Retreat findings and insights [pdf]

#30

Post by bmurphy1976 »

NeutralForest wrote: post #9

I thought it was generally interesting but it needs to materialize into processes and tools people can use.

That's kind of the point. These things don't just happen, people start talking about it at a high level (this doc, conversations like this) and then dig in and solve the problems over time.
Post reply on HN