4 ms·
That's not what the programmers want. It's how they're incentivized. If you have to meet your "they're not deadlines but, really, they are" sprint targets, then
by cs137 4y ago
That's not what the programmers want. It's how they're incentivized. If you have to meet your "they're not deadlines but, really, they are" sprint targets, then what can you do but minimally complete the tickets assigned to you and hope not to step on anyone's toes?
It doesn't help that good programmers get flushed out of the industry due to conscience and age, only to be replaced with cheap, shitty ones.
- tsss 4y agoNo, in my case that's really what they want. I think our project management would totally give us the time to improve something, if we can argue that it's needed. It's really one or two developers who block everything that isn't the absolute minimum possible amount of work or their own pet idea.
- mgkimsal 4y ago> I think our project management would totally give us the time to improve something, if we can argue that it's needed. You shouldn't have to argue for it. It's something "project management" should care about as a top-level concern, scheduling time for it. Stability, documentation, tests, performance, security - these are all "features" just as much as "make a button dump a CSV for a user".
- tsss 4y agoI mean, they do to the extent that they can. We have a story template that specifically mentions performance, monitoring, security and documentation requirements. We also have weekly meetings to discuss technical issues and a dedicated backlog where devs are supposed to put purely technical stories, but it is usually empty. When the prevaling philosophy of the dev team (or its most vocal members) is "'good enough' is good enough", then there's not much the project management can do short of forcing a minimum amount of maintenance tasks. Of course, project management is also happy if they have more capacity for feature stories, so the impulse has to come from the dev team.
- tacitusarc 4y agoOften (good) PMs assume that those tasked with making technical decisions implicitly understand all the listed concerns are, in fact, requirements. They are then surprised when the engineers explain they didn’t prioritize those things when doing the work.