Als Antwort auf Ludic 🧛

Definitely it's an issue if developers are getting into trouble for going over the estimate. Management will likely get the opposite of what they want out of that move, as developers pad their estimates.

Nonetheless, it seems reasonable to me to break up a task into components at the outset if you think it will take more than a week. Looking back at my career I can't remember any time when I had a branch open longer than a week and it was a good idea.

Als Antwort auf Dethrone Dog

@sanedragon I never had a week-long branch on a functional team, yeah.

Where I'm seeing that get janky now is when it's at a place that has already let engineering discipline slip, because it becomes really hard to fix really gnarly architectural mistakes in 3 day increments. Like, totally untested codebase, database access is provisioned through a spreadsheet, it is HARD to come up with a plan I can deliver piecemeal.

Als Antwort auf Dethrone Dog

@Dethrone Dog @Ludic 🧛

In my current project, lots of stories take weeks. Even small ones that take only a few days will inevitably take weeks to complete, partially because our application really is that complex, but mostly because our CI street is that complex, and it can take days before all the automatic tests are green, and then a tester sends it back because they want more from this feature.

Als Antwort auf Martijn Vos

@mcv That sounds terribly frustrating. I would say that a testing process that takes days and gates integration can't really be described as "continuous integration". It would likely benefit your team to have feature flagging, to enable new feature code to get integrated before QA is complete on it, and to get a regression test suite that can complete in under an hour that you can use to gate integration, and run the full days-long suite against the main branch on a schedule.
Als Antwort auf Dethrone Dog

@Dethrone Dog @Ludic 🧛

The test suite takes a bit over an hour, but there's always something that randomly fails, so you end up spending days hunting rerunning tests and checking if maybe it's a legitimate error that requires fixing. Or Sonar decides that you touched a file that doesn't have sufficient test coverage. And then something else has been merged and you need to fix a bunch of merge conflicts. And then one of a bunch of dependencies starts causing errors.

The real problem is that we've got 20 devs on a single complex code base. It's actually working much better than you'd expect, but it does create a lot of overhead and frustration.

Als Antwort auf Old Fucking Punk

@Old Fucking Punk @Ludic 🧛

Anyone who ever really cared about valid software metrics wouhld be conversant with Capers Jones and would never, ever use something as unscientific as story points to try to measure software effort.


That's a ridiculously absolute statement and obviously wrong.

And the whole reason story points are so explicitly vague is that there is no reliable scientific method to measure "software effort".

Als Antwort auf Martijn Vos

@mcv Capers Jones, IFPUG, etc., have a lot of data that shows how software effort is measurable and predictable. It's not perfect and there are gaps, but that's mostly due to a lack of acceptance. FUD abounds.

In the software world, it's easy to shout, "Perfect is the enemy of the good!", and invent a new 3GL rather than evaluate if it'll be a waste of time.

@ludicity

Als Antwort auf Old Fucking Punk

@Old Fucking Punk @Ludic 🧛

I have no doubt that Capers Jones has valuable insights, but this is honestly the first time I've heard of him, so I'm pretty sure a lot of people out there haven't. Thanks for mentioning him, though; I'll definitely look him up.

But I remain sceptical about the ability to accurately and scientifically measure and estimate programming effort. It's a problem that has stumped people for decades, and I'd expect a lot more noise if someone had definitively cracked it.

Als Antwort auf Martijn Vos

@mcv @lwriemen I haven't heard of Jones, though @anEXPer sent me this a while ago: daverooneyca.substack.com/p/ul…

At this point in my life, I don't think about this very much. Teams of cosplaying engineers have bigger problems, and teams of serious people that have gelled socially will find something that works for them. The latter group can optimize a lot, but I've only gotten that far very recently and we have other issues as a new business.

Als Antwort auf Ludic 🧛

@mcv @anEXPer
I have a very short list of people to listen to regarding software development:
1. Sally Shlaer and Steve Mellor for system structure and software modeling.
2. Tom DeMarco and Tim Lister for software management.
3. Capers Jones for software effort measurement.
4. C. J. Date for database.
Hopefully there are younger people continuing their work.