[geekbird]

IMO it's partly a problem between sales and the "sprint" based development. Everyone wants fast, new and shiny and a 2 week sprint. No one wants to do tests, maintenance or even any architectural planning for their software beyond a single sprint, and architectural decisions don't flow between sprints. That's what happens when entire companies cargo-cult adopt scrum for their "agile" process, and the software suffers from the engineering equivalent of quarterly report syndrome (nothing longer than a quarter is really planned out in many publicly held companies because shareholder earnings reports are the highest priority.)

Yes, I'm cynical.

[dyldog]

I think it's this, but this is just one symptom of the real problem, which is too many so-called "non-tech" people in the tech industry. There's no way a person who isn't a really good programmer (or something close to it) can effectively make decisions on a day-to-day basis. That's why managers have to guess or defer to a tech lead when it comes to real technical decisions/conversations (hence the tech lead who lives in meetings with the client).

To use a metaphor, imagine if a project manager at a car company boasted about "not being a car person", or couldn't explain how the main parts (like the engine) worked. Yet, this is pretty much the norm in many areas of the industry; tech is a cash cow, so it's attracted people with a desire for money where their knowledge and experience should be. You can't really fake it being a programmer, so they've only been able to infiltrate managerial positions.

(And to be clear, the way the tech industry supports people learning is fucking tops. I'm not talking about those people, I'm talking about people (mostly managers) who are not concerned about their basic lack of knowledge)

Yes, I'm also cynical.

[solardev]

Another perspective... software in particular skews the usual production economics because of its low per unit cost vs the extremely high scalability and thus need for marketing and other business support.

A furniture business with ten people producing the furniture would probably max out their production with just a tiny bit of non carpenter support.

A software business with ten devs, on the other hand, could grow from tens to millions of users with the right non tech support, whether it's marketing or seeking VC funding, even if the underlying product only barely kept growing.

Most of these processes are there for business needs, not dev needs, with the company trying to maximize the value of their super expensive devs.

It's the assembly line model of software dev, where some higher up decides what to build and chunks it into individual production stations that each just produces their part with minimal fuss. In this world, managers don't need technical skills as much as waterfall skills. The spirit of it is completely different. It's not meant to enhance developer creativity but restrain it so that it's focused on a predefined chunk of business need.

[britch]

Is this really true at car companies? I don't know, legitimately curious

My sense at least is that at some point every company becomes "interchangeable people with business degrees and MBAs"

I agree that line is fairly low in tech, but curious about other industries

[brailsafe]

Absolutely agreed. I'm on a team that is presently working on some rewrites of major components in our app from an older frontend framework to React with TS. It takes a while to get to even parity, it's tedious, and tricky to get right, and 3 of us are independently working on separate major bits concurrently. We also have other stuff, code reviews, meetings, Jira, other bugs to fix, and the 2 week sprint just makes it feel like I'm constantly on edge, because it's not going to be anywhere useful in 1 sprint or likely 2, and it doesn't offer any breathing room. Having more two week blocks rather less longer blocks of time also introduces more of the overhead that accompanies agile crap, and reduces time to get the stuff done even further. If we know it'll probably take 4-6 weeks to do something to the standard we want it, we should probably at least be doing 3 week cycles, or dynamically change it depending on our goals, but that never happens.

2 week sprints optimize for fast, poorer quality work, and much less of it, because for a healthy practice one needs margin. Margin to accept other pointless meetings, margin to deliver hotfixes, margin to do work carefully without burning out.

Yes, I'm cynical.

[s2th4d]

You're not the only one. I too am also doing somewhat of a similar migration with similar staffing and not enough time, and the project managers and product owners are more concerned ed about the dates they committed to than what us devs need to make it all possible. The last site works, but it has dragons and monsters under the hood.these things take time, but because us devs are not able to clearly estimate.the end of the line, we stick with the too tight time frames...

[tartoran]

Exercise saying “No” as much as you can. The less you say it the more it becomes a like a right stripped away.

[throwaway_bags]

Yeah we have 2 week springs inside ~quarter long projects. But I find the projects come and go and I'm still providing weekly user support for projects that "ended" quarters ago. Like there's no company dialect word for "platform".

[MrDresden]

Mirrors my experience somewhat. Often these places are feature factories that heavily advertise their scrum/agile practices without actually thinking about if they apply or fit (or are even implemented correctly).

What often follows is a thick layer of success theatre with each feature release.

Rinse repeat.

Any voices trying to point the flaws, inefficiencies or low hanging fruits for doing things better are drowned out or made to feel the odd one out.

I know, as I have been one of those voices.

[filoeleven]

Rich Hickey on sprints (30 second video): https://youtu.be/zPT-DuG0UjU