I'm currently watching someone use story points as time estimates (1 point = 1 day), but ALSO using the heuristic that 5 points is too much (which is for when story points represent complexity), so now no one is ever allowed to work on one thing for five days.

💀

I move ever closer to my villain arc.

@ludicity desert or volcano evil lair?
@Viss You gotta rock the volcano, the entrance has to be in a skull's grinning mouth, the classics are classics for a reason.
@ludicity what about a mountainside lair built into a cliffside, only accessible by gondola?

@Viss I'll concede you're cooking.

I just tried to find you a link to the Dr McNinja chapter titled "Punch Dracula" but apparently the website is down.

@ludicity 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.

@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.

@ludicity Oof, no tests makes it rough. Fixing that has to be a top priority. Hard to convince management that you need to spend time on changes they can't see, though. I don't envy your position.
@sanedragon Yeah, it's tricky, but there are worse things to be doing I suppose! The main reason it's frustrating is, of course, that having to do all that teaching means you're not learning that much. It's a hard struggle in Melbourne to find a team to learn from.

@sanedragon @ludicity

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.

@mcv @ludicity 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.
@mcv @ludicity It's one thing if it takes weeks (or even months) for users to see the results of a developers work. But (at least according to Continuous Integration doctrine) code should be completed in small chunks and integrated as quickly as possible (within a day, although no team I've been on has achieved that in all cases)

@sanedragon @ludicity

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.

@mcv @ludicity The more devs you have the more important it is to integrate quickly to avoid conflicts! It sounds to me like moving some of these checks that are gating integration to after code is integrated (but before the task is considered complete) would help.

@sanedragon @ludicity

Yeah, that's the neverending discussion here. Maybe we need two main branches: one before the full test run and one after.

I'm coping, but it does make me eager to work on something on my own again.

@ludicity

“let’s use yellow to indicate importance, no wait— urgency, no wait, either importance or urgency…” 🤪

@ludicity yes and now try for five minutes
@ludicity Now you have to wait for a story to take longer than it should. Then you can watch someone cover their ass, saying story points don't handle dealing with individual developer skill level. Thus rendering them even more meaningless. At this point I'm like that guy from the matrix. I don't see numbers just redhead or brunette.
@ludicity seen a manager desperately converting T-shirt sizes into days...
@ludicity 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.
#DumbAllOver

@lwriemen Is Capers Jones on LinkedIn though? Because if they aren't then I ain't interested.

Speaking of which, when did LinkedIn rebrand to Mastodon, and how do I get the old UI back?

@lwriemen @ludicity

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".

@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

@lwriemen @ludicity

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.

@mcv @lwriemen I haven't heard of Jones, though @anEXPer sent me this a while ago: https://daverooneyca.substack.com/p/ultimately-theres-no-point

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.

Ultimately, There's No Point!

Seriously - don't use Points. I'm not kidding. Stop it! Now!

Embracing Agility
@ludicity @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.
@ludicity
our team PM: story points represent developer effort, not time scripts take to run
also our team PM: why is your 1 pt story still not done 🧐 (it runs for 3 days)
@geograpfer I see that we live in the same layer of hell.