Why Doesn't AnyType Prioritize Development Speed?

[ThatGuy]

@zma17

Could you please link that? I saw his update a year ago on the estimated wait time for a bunch of anticipated features, but don’t recall seeing anything addressing the problems and how they plan to approach them.

It’s in this thread. Short version - they’re having to do some major redesign of the architecture because they’ve run into some blocks, so while that’s going on, they’ll focus in th next 3 months or so on bug fixing and other basics.

@zma17

What alternative do you propose (if any)?

GitHub is the obvious place for bug reporting and feature requests. I’m sure there are users here who aren’t familiar with Github but it’s not that hard to use.

@zma17

@ThatGuy

Golden rule of software development: if a project is late, expanding the team makes it later. Double the impact if the team is working on things that haven’t been done before: no routine tasks to offload onto newbies; no previous experience to inform estimates; no view of what issues are most likely to arise.

This, I did not know, but can understand when broken down like that… still, though, it’s not a satisfying conclusion. There’s got to be a solution somewhere. There’s got to be something(s) that can speed things up and smooth over the process.

Most people outside project management don’t know this. It’s a major cause of repeated and amplified delays. Unless this is recognised, there’s a big temptation to throw bodies at it. The problem is that extra bodies (a) increase management overhead (bigger team = more management work) (b) take time from experienced team members to train/induct new team members (c) add extra cost/time waiting for new team members to become productive and (d) add risk of wasted cost if new team members don;t work out well.

Of course, there are exceptions: it might be possible to package up some non-core work and hand it over to newbies/externals to release key resources; there may be a very specific blockage that a very specific additional resource could unblock’ it might be that the team was seriously under-resourced at the start. But the solution to this last one isn’t to add bodies - it’s to pause and replan based on a better understanding of the problem. Which sounds similar to what @anton was talking about in the linked thread.

@zma17

I’m also trying to affirm–perhaps poorly so far?–that our intentions aren’t malicious, even if sometimes our frustration spills over. I imagine it’s a nasty feeling, to face someone’s frustration when it also comes with a lot of care–you can’t be fully angry in response, but you’re also still involved in a conflict and therefore want to defend yourself. Very complex situation, perhaps one of the worst ones to be in. I’m sorry to put them in it. It’s almost a toxic thing, and I don’t intend for it to be such… the good news is that we can leave all this behind, though, with just more stable updates and communication (I’m sounding like a broken record at this point, I know).

This is an interesting one. Stakeholders who are unhappy with a project are almost always unhappy because they want it to succeed (rare cases where a stakeholder really doesn’t, but that’s a different subject ). Emotions often run very high - people can be so convinced that they know what’s wrong and how to fix it that the project team feels attacked. After all, the team knows it has issues. That damages confidence, and then any external criticism, however well meant, feels like an attack.

In those circumstances, it’s a big ask to expect the team to engage with stakeholders, but there’s an obligation on the team leadership there. I’m in danger of sounding like I’m attacking, but I’m not. I’ve been there.