[PaulHoule]

Ouch!

I’ve worked in two kinds of organizations. In one of them when there is a ‘small’ ticket from the viewpoint of management, one programmer is responsible for implementation but might get some help from a specialist (DBA, CSS god, …)

In the other a small ticket gets partitioned to two, three or more sub teams and productivity is usually reduced by a factor more than the concurrency you might get because of overhead with meetings, documentation, tickets that take 3 sprints to finish because subtasks that were one day late caused the team to lose a whole sprint, etc.

People will defend #2 by saying thar’s how Google does it or that’s how Facebook does it, but those monopolists get monopoly rents that subsidize wasteful practices and if wall street ever asks for “M0R M0NEY!” they can just jack up the ad load. People think they want to work there but you’ll just get a masterclass in “How to kill your startup.”

[irrational]

I’ve worked at the same company for a long time. For about 15 years, my team was embedded in a business team and we managed things however we wanted. We could move very quickly. Then, about 5 years ago, we were moved into the tech organization. We were forced to adopt agile, sprints, scrum masters, jira, stand ups, etc. It probably takes 10 times longer to get the same amount of work done, with no improvement in quality. The amount of meetings is truly astonishing. I’m convinced the tech org mainly exists to hold meetings and any development work that occurs is purely accidental.

[chiefalchemist]

But is your loss from adopting those teach standards, or from being un-embeded in the business team?

Tech orgs and those standards exist because:

- tech generally doesn't understand business - the business struggles to express it's needs to tech

Embedding worked for you, but how big was your team? Could that scale?

I'm not questioning your success or your frustrations, but how unique was the situation for your success?

[0xblinq]

Same experience as me. Scrum is a disease in this industry.

[tomnipotent]

What you may not see is quality-of-life improvements for executive management, planning, and scheduling. Communication and alignment can be both more important and more profitable than just velocity alone.

[charrondev]

I work at a company that makes a very clear distinction between API and View layer. Our API spans 200+ endpoints. We have 6 backend and 6 frontend developers.

As far as iterations go it’s very rapid. Our work teams are split into 1 backend and 1 frontend developer. They agree on an API spec for the project. This the contract between them and the frontend starts working immediately against a mock or very minimal version of the API. Iterate from there.

[respondo2134]

This is a pretty popular approach, and I use it sometimes, but "agree on an API spec for the project" does gloss over how challenging and time consuming this can be. How many people here have ever gotten their API wrong? (raises hand). There's still a lot of ongoing coordination and communication.

[charrondev]

Oh certainly. It’s pretty rare to get things exactly right on the first try. For this reason we hide new endpoints from our public open api spec and documentation until we are satisfied that some dust has settled on them a little bit.

Still you only have to get it mostly right. Enough to get started. This only starts to become a huge problem when the endpoints is a dependency of another team. When you’re in constant communication between the developer building the API and the developer building the client it’s easy to adjust as you go.

I find a key part of a workflow like this though especially if you have multiple teams is to have a lead/architect/staff developer or whatever you may call it be the product owner of the API.

You need someone ensure consistency and norms and when you have an API covering functionally as broad and deep as the one I work on, it’s important to keep in mind each user story of the API:

- The in house client using the API. This generally means some mechanism to join or expand related records efficiently and easily and APIs providing a clear abstraction over multiple different database table when necessary. - The external client, used by a third party or the customer directly for automation or custom workflows. The biggest thing I’ve found helps these use cases is to be able to query records by a related field. For example if you have some endpoint that allows querying by a userID, being able to also query by by a name or foreignID passed over SSO can help immensely.

[treeman79]

Yep. I was in a type 1 startup. Stuff got done fast.

Company forced us to type 2 using Angular. projects thar used to take a couple of days for one person became multi month efforts for a dozen developers across three teams.

[ResearchCode]

Sounds like the problem is having "sprints". As far as I know, most teams at Google and Meta don't.

[respondo2134]

They need scaled agile, where every 5 or 6 sprints you group them into an program increment, with extra overhead and even more ridiculous symbolic rituals. Your team is held to an arbitrary commitment months out, then executives shift the ground under your feet and make everything irrelevant. Dev teams love it!

</s>

[ResearchCode]

It's remarkable that non-tech enterprise need all this agile for poor internal CRUD apps, but FAANG-scale product development somehow does not.

[mdmglr]

What do teams at google and meta practice?

[dial9-1]

it's called resume-driven development

[wahnfrieden]

Speaks some truth to Graber's Bullshit Jobs thesis