|
rt4 posted:Why do I even know who that blowhard is? I'm under the impression he wrote some useful piece of software 30 years ago or something? Close. He hung out with people that wrote useful software 30 years ago. He’s most well known for having opinions on software and the game rogue. Not for functional contributions of work.
|
#
?
Jun 21, 2019 12:10
|
|
|
|
| # ? May 11, 2024 15:02 |
|
|
shrike82 posted:The grossest hygiene thing I've seen with a colleague is a person who, I'm not sure how better to describe this, would sometimes have a coating of white, dried spit around their mouth. Unfortunately, their manager and HR can't do much about that since rabies is a health condition.
|
|
#
?
Jun 21, 2019 12:38
|
|
|
leper khan posted:Close. He hung out with people that wrote useful software 30 years ago. Fetchmail and the Jargon file as well.
|
|
#
?
Jun 21, 2019 17:10
|
|
|
ulmont posted:Fetchmail and the Jargon file as well. In the movie Revolution OS he even joked about fetchmail how it was written by such a young and inexperienced programmer and he had to come and rescue it. One of the many cringey moments of that "movie".
|
|
#
?
Jun 21, 2019 18:05
|
|
|
esr is a genuinely foul human being on several axes. not having to deal with him any more was a highlight of leaving a previous job. I get angry just thinking about him
|
|
#
?
Jun 21, 2019 19:02
|
|
|
Subjunctive posted:not having to deal with him any more was a highlight of leaving a previous job. I am very curious about real-life esr interactions, if you are up for sharing any stories.
|
|
#
?
Jun 21, 2019 19:33
|
|
|
ulmont posted:Fetchmail and the Jargon file as well. this is spot on leper khan posted:Close. He hung out with people that wrote useful software 30 years ago.
|
|
#
?
Jun 21, 2019 19:43
|
|
|
Subjunctive posted:esr is a genuinely foul human being on several axes. not having to deal with him any more was a highlight of leaving a previous job. I get angry just thinking about him 
|
|
#
?
Jun 21, 2019 20:50
|
|
|
Just looking at his Wikipedia page and 
|
|
#
?
Jun 21, 2019 21:12
|
|
|
But that's not enough. We need a Linus versus esr page. Namely, "Is Mrs/Mr Doe Agile, agile, or not?" ... versus Stallman versus Royce versus de Raadt vs Gates...
|
|
#
?
Jun 21, 2019 22:51
|
|
|
And the other problem with agile methodologies rears its ugly head: We shall assume that tasks are performed by interchangeable clods with equivalent institutional knowledge. Too bad that risk planning is "planning" and that's not agile. Really looking forward to the review of this project after it completes. I really hope they're willing to look at how things were ultimately delivered.
|
|
#
?
Jun 24, 2019 23:16
|
|
|
Wait, are they transfering pointed tasks between teams?
|
|
#
?
Jun 24, 2019 23:44
|
|
|
PhantomOfTheCopier posted:And the other problem with agile methodologies rears its ugly head: We shall assume that tasks are performed by interchangeable clods with equivalent institutional knowledge. But working around the fact that you can't plan who is going to work on a given user story is the entire point of not providing specific hour estimates and instead going off of points, with higher pointed items being of higher uncertainty? And it's not on a person by person basis, but the team, so it doesn't matter if Joe works faster than Jane. Agile actually can work, but just like anything else, it depends on people understanding why they're following a certain process and doing things the way they're doing them, instead of just cargo culting. New Yorp New Yorp fucked around with this message at 23:54 on Jun 24, 2019 |
|
#
?
Jun 24, 2019 23:48
|
|
|
PhantomOfTheCopier posted:And the other problem with agile methodologies rears its ugly head: We shall assume that tasks are performed by interchangeable clods with equivalent institutional knowledge. Too bad that risk planning is "planning" and that's not agile. When we estimate our stories and there is disagreement about how much it should take we always as a team decide on the larger number to allow for less experienced people being the ones to work on it.
|
|
#
?
Jun 24, 2019 23:52
|
|
|
But then every story becomes at least a "Large", though?
|
|
#
?
Jun 25, 2019 13:14
|
|
|
BusError posted:I am very curious about real-life esr interactions, if you are up for sharing any stories. I met him at a convention once and he tried to convince me that the United States invented the chili pepper.
|
|
#
?
Jun 25, 2019 13:14
|
|
|
PhantomOfTheCopier posted:I really hope they're willing to look at how things were ultimately delivered. You've been in this industry how long now?
|
|
#
?
Jun 25, 2019 13:19
|
|
|
Janitor Prime posted:When we estimate our stories and there is disagreement about how much it should take we always as a team decide on the larger number to allow for less experienced people being the ones to work on it.
|
|
#
?
Jun 25, 2019 14:24
|
|
|
Story points and velocity are dumb as gently caress.
|
|
#
?
Jun 25, 2019 16:16
|
|
|
Rubellavator posted:Story points and velocity are dumb as gently caress.
|
|
#
?
Jun 25, 2019 16:22
|
|
|
Sagacity posted:But then every story becomes at least a "Large", though? That's how it worked at my old job. Well, we did Fibonacci numbers, not sizes. But still. "Here's a project in some code you're not familiar with. Story point it, please." "Uhh, well, nobody here knows that feature or codebase. 13." Next story. "Nobody knows that feature or codebase... 13." At the end, every story was a 13, with a team agreement to re-point in the middle of the project. All because we had to story point everything NOW even if our estimates were completely off base.
|
|
#
?
Jun 25, 2019 16:26
|
|
|
Isn't it great how every Scrum company just keeps pressing forward like that, instead of going, "Wait, this isn't working. Let's examine why this isn't working and fix it."
|
|
#
?
Jun 25, 2019 16:46
|
|
|
CPColin posted:Isn't it great how every Scrum company just keeps pressing forward like that, instead of going, "Wait, this isn't working. Let's examine why this isn't working and fix it." No kidding. If only one of the tenets of agile development was to reflect on the process at regular intervals and implement constant revision where necessary... Of course, at many companies, if you point anything like that out, you're not rewarded for and often discouraged from rocking the boat.
|
|
#
?
Jun 25, 2019 16:49
|
|
|
Rubellavator posted:Story points and velocity are dumb as gently caress.
|
|
#
?
Jun 25, 2019 16:53
|
|
|
Vulture Culture posted:Congratulations on estimating stories in hours In practice they are more like dev days, which gives enough wiggle room to plan for capacity accordingly. Protocol7 posted:That's how it worked at my old job. Well, we did Fibonacci numbers, not sizes. But still.
|
|
#
?
Jun 25, 2019 16:59
|
|
|
So, wait, you're all saying that cargo culting into a process or technology doesn't work? 
|
|
#
?
Jun 25, 2019 17:10
|
|
|
Janitor Prime posted:Our tech leads and BA's groom all the stories before estimation with as much background and technical details as possible to be able to estimate things better, and we don't work on code bases that aren't part of our project which helps. I wish. That old job was a hellhole of hamfisted process (SAFe being chief among them and a gigantic waste of agilefall time) and tossing things over the walls back and forth between dev and QA (i.e., not just working together to solve problems.) The only reason I stayed is because for the last 6 months I could work from home 24/7 and do nothing but play video games, but even that wears its welcome out after some time.
|
|
#
?
Jun 25, 2019 17:15
|
|
|
Protocol7 posted:No kidding. If only one of the tenets of agile development was to reflect on the process at regular intervals and implement constant revision where necessary... Uhh I don't see anything about constant revision in the enterprise agile manifesto
|
|
#
?
Jun 25, 2019 17:30
|
|
|
sunaurus posted:Uhh I don't see anything about constant revision in the enterprise agile manifesto Ugh, don't remind me about that. The part that says "we have mandatory processes and tools to control how those individuals (we prefer the term ‘resources’) interact" hits too close to home on my old job. Especially the part where our management referred to devs as resources.
|
|
#
?
Jun 25, 2019 18:09
|
|
|
Protocol7 posted:Ugh, don't remind me about that. The part that says "we have mandatory processes and tools to control how those individuals (we prefer the term ‘resources’) interact" hits too close to home on my old job. Especially the part where our management referred to devs as resources. That term is one of my biggest buttons I swear to christ.
|
|
#
?
Jun 25, 2019 20:51
|
|
|
We had "People, not Resources" hammered into us at the last Scrum training I had the pleasure of attending and none of the managers caught on.
|
|
#
?
Jun 25, 2019 21:08
|
|
|
resources is a fine word, dehumanize yourself and face to corporate
|
|
#
?
Jun 25, 2019 21:13
|
|
|
Unfortunately, I'm afraid you all missed it. Points or hours are irrelevant. The false assumption is that engineers are interchangeable during the task, and since there's no plan and no risk plan, things fall apart as a result of the exchange. A 5pt task that has undergone "1pt of work" returns to a 5pt task when the engineer is flopped out for a "higher priority". A 5hr task likewise. By rapidly exchanging people you could probably arrive at Zeno's Paradox of Productivity, that "Assigning everyone to everything yields zero velocity".
|
|
#
?
Jun 25, 2019 21:19
|
|
|
The finance industry calls this department "human capital" and I'm not sure if it's better or worse
|
|
#
?
Jun 25, 2019 21:25
|
|
|
PhantomOfTheCopier posted:Unfortunately, I'm afraid you all missed it. Points or hours are irrelevant. The false assumption is that engineers are interchangeable during the task, and since there's no plan and no risk plan, things fall apart as a result of the exchange. This is a people problem. Once work begins on a sprint, the sprint should be considered "locked" -- no new work comes in, critical "everything is on fire" issues notwithstanding. If you're working in small enough sprints, that shouldn't be a problem, because the team's priorities can shift every week or two depending on the product owner's whims. If someone is coming in and trying to change sprint priorities around after work starts, there should be someone putting their foot down and saying "no". You're still blaming the process for problems caused by people trying to circumvent the process because they don't understand it.
|
|
#
?
Jun 25, 2019 21:25
|
|
|
PhantomOfTheCopier posted:Unfortunately, I'm afraid you all missed it. Points or hours are irrelevant. The false assumption is that engineers are interchangeable during the task, and since there's no plan and no risk plan, things fall apart as a result of the exchange. This is just a symptom of bad management. The only changes to a team or a developer's workload should happen in sprint planning, and nowhere in between. And even then, if anything changes in planning, like a developer switches teams or the tasks assigned to the team change at all, the existing numbers from pointing or estimations are basically meaningless anyway. The problem is made worse by bullshit estimation numbers being used as some measure of developer or team productivity, and if anything changes during the sprint, or even during sprint planning, the volatility of that magic productivity number means it's also meaningless, which means your process is mangled. Macichne Leainig fucked around with this message at 21:35 on Jun 25, 2019 |
|
#
?
Jun 25, 2019 21:31
|
|
|
Process doesn't exist without people, and process induces certain behavioral patterns that create these issues. I'm blaming the process, not necessarily for the initial issues created by the people, but for it having a general approach that also ignores "safety mechanisms" that prevent those issues from snowballing into catastrophies.
|
|
#
?
Jun 25, 2019 21:35
|
|
|
PhantomOfTheCopier posted:Process doesn't exist without people, and process induces certain behavioral patterns that create these issues. I'm blaming the process, not necessarily for the initial issues created by the people, but for it having a general approach that also ignores "safety mechanisms" that prevent those issues from snowballing into catastrophies. I think it would work if a company truly adheres to an agile process. See that DoD "Detecting Agile BS" document. Chances are your company calls themselves agile but also hit many of the checkmarks of that document. I have a feeling the problem is a lot of management wanting the niceties of agile, but not being able to give up the rigidity and perceived stability of a waterfall process. And also not having any fundamental understanding of what makes a development team successful, let alone what makes an individual on that team succeed in their role. The dehumanizing aspect of calling developers "resources" and assuming that resources are interchangeable certainly applies here.
|
|
#
?
Jun 25, 2019 21:41
|
|
|
Vulture Culture posted:The finance industry calls this department "human capital" and I'm not sure if it's better or worse Considering that basically means "non-consumable property", it's... mixed, I guess?
|
|
#
?
Jun 26, 2019 16:15
|
|
|
|
| # ? May 11, 2024 15:02 |
|
|
Protocol7 posted:That's how it worked at my old job. Well, we did Fibonacci numbers, not sizes. But still. We do the opposite. Don't know that feature it code base? 2 points
|
|
#
?
Jun 26, 2019 18:37
|
|
