|
Kevin Mitnick P.E. posted:Things that don't matter: yup totaly irrelevant
|
#
?
Apr 10, 2019 01:14
|
|
|
|
| # ? May 27, 2024 07:23 |
|
|
Guess I wasn't too clear in that post cause I sure didn't mean to imply that it never ever matters, ever, no matter what, what HTTP verb you use for an endpoint. Only that it doesn't matter in itself. Put something non-idempotent behind a GET? You have made a broken thing enjoy it. Nomnom Cookie fucked around with this message at 15:35 on Apr 10, 2019 |
|
#
?
Apr 10, 2019 02:01
|
|
|
Yesterday I implemented a PATCH operation behind a PUT verb because the router that takes care of traffic from external sources (like, you know, a SPA running on a cunsumers machine) does not handle PATCH. Simply not in there, they all get routed as GET. So we use PUT. We put an object that contains a JsonPatch operation to patch the object of which the key is in the URL. Our resident Guardian of Standards looked very sad.
|
|
#
?
Apr 10, 2019 07:14
|
|
|
Our server admins once restricted anything that wasn't GET or POST per a security requirement.
|
|
#
?
Apr 10, 2019 14:24
|
|
|
Rubellavator posted:Our server admins once restricted anything that wasn't GET or POST per a security requirement.
|
|
#
?
Apr 10, 2019 14:27
|
|
|
Pushed a new build out to our team's QA server. It had been 6 days since the last build and there were a few PRs, one of which was very large, since the latest deployment. The big PR hosed up the ability to log into the application (because of course the loving developer didn't build and test their changes...), so QA opened up a bug, put it under the story for the big PR, and then moved my completely separate user story from "Ready to Test" to "Active" for reason of "Test failed." They won't change it back despite that the issue is tracked with a separate bug ticket under a separate user story, so my daily standup update is literally just "Waiting to move my user story back to Ready to Test when the bug is fixed." There's no issue with the code I pushed, they just don't want it "Ready to Test" until the build is actually working. I hate process for the sake of process.
|
|
#
?
Apr 10, 2019 15:54
|
|
|
Protocol7 posted:Pushed a new build out to our team's QA server. It had been 6 days since the last build and there were a few PRs, one of which was very large, since the latest deployment. I had this exact same conversation a couple months ago with my boss, from your perspective, and I came around to seeing the other side instead. We kind of take stuff personally, and when things come back to us from QA, it's like defending against an attack on the quality of our work. Devs own their own specific deliverables, but QA doesn't—they're event-driven. They get notified that there's something to run, they test it, then they drop it somewhere else. Their whole flow gets hosed up if you have to suddenly insert an interval polling thread because a bunch of the stuff marked Ready to Test is not, in fact, Ready to Test.
|
|
#
?
Apr 10, 2019 16:26
|
|
|
This burned Google when they did some distributed web cache thing ages ago too. Forum admins were automatically deleting posts via prefetch, it was glorious. I can’t remember the name of the product (it also did desktop search, I think), or I would try to find the team’s “welp” post about it. (I bet the piece of software referenced in the above tweet is a snarling mess of CRSF issues too.)
|
|
#
?
Apr 10, 2019 16:32
|
|
|
Vulture Culture posted:It's frustrating, but if you look at this another way: from the perspective of a tester, using a test environment, is your story Ready to Test? I'd agree in circumstances where teams don't have great communication, but when you can just say in a Teams message something like "Story XXX has been checked in and will be in the next build," it seems kind of like a moot point. It's also more frustrating because this status switching has definitely not been the norm on our team, so I don't really know what changed. I enjoyed working on this team mostly because we were great at keeping each other in the loop, and more importantly, accountable, but it doesn't seem like that's the case anymore. I do get it, I guess I'm more frustrated about the general lack of consistency. If anything is most frustrating, it's that the other developer pushed out a PR with 16 (!!!) updates, most of which happened after the initial review and PR approvals, which just doesn't give me confidence in the code they're checking in. And, seeing that it broke the software, rightfully so. Macichne Leainig fucked around with this message at 17:05 on Apr 10, 2019 |
|
#
?
Apr 10, 2019 16:56
|
|
|
How about this: You are a tester and know that a few big ticket things are coming that you need to test under time pressure. Anything that has status "Ready for Test" will be on your plate and you will catch management attention if things are in that state for to long, no matter the reason. Also, the ability to move status of the stories is about the only tool you have to control your fate. You should stop taking story status as serious as the testers do, or do you get management flak from having the story in Test Failed for to long? From your responses it seems that the testers got in trouble and now simply cover their asses. Or they watched some webinar or something.
|
|
#
?
Apr 10, 2019 17:11
|
|
|
Protocol7 posted:I'd agree in circumstances where teams don't have great communication, but when you can just say in a Teams message something like "Story XXX has been checked in and will be in the next build," it seems kind of like a moot point. It's also more frustrating because this status switching has definitely not been the norm on our team, so I don't really know what changed. If it was me, I'd just mark the story as "Blocked By..." and refer to the bug/story that broke login. And the update in stand up is "Blocked by other developer." Because from the stand up that's the case. Your story is blocked by that developer.
|
|
#
?
Apr 10, 2019 17:59
|
|
|
Hughlander posted:If it was me, I'd just mark the story as "Blocked By..." and refer to the bug/story that broke login. And the update in stand up is "Blocked by my seething hatred for other developer." Because from the stand up that's the case. Your story is blocked by your seething hatred for that developer.
|
|
#
?
Apr 10, 2019 19:42
|
|
|
Hollow Talk posted:my seething hatred for other developer."
|
|
#
?
Apr 10, 2019 20:34
|
|
|
Introduce a new state in between In Progress and Ready For Testing. Move the story to this new state when your work on it is done, then advance it again when it has been deployed to the test environment.
|
|
#
?
Apr 10, 2019 20:57
|
|
|
All problems with ticket workflow can be solved by adding another ticket state, except for the problem of too many ticket states.
|
|
#
?
Apr 10, 2019 22:01
|
|
|
If you have too many ticket states, just collapse them so multiple ticket states show up in the same column on your board, and
|
|
#
?
Apr 10, 2019 22:01
|
|
|
We have 3 states: todo, in progress, and todid.
|
|
#
?
Apr 10, 2019 23:25
|
|
|
Clanpot Shake posted:We have 3 states: todo, in progress, and todid. We have 3 million states, depending on if you have a task, a story, a bug, an epic, a subtask, or any of the other dozen issue types that I don't deal with.
|
|
#
?
Apr 11, 2019 00:02
|
|
|
lifg posted:We have 3 million states, depending on if you have a task, a story, a bug, an epic, a subtask, or any of the other dozen issue types that I don't deal with. I started playing around with Azure Devops Boards just to see what it’s like and it totally has this problem. Each work item type has a completely different set of states and it’s this huge, unnecessary cognitive load.
|
|
#
?
Apr 11, 2019 14:01
|
|
|
raminasi posted:I started playing around with Azure Devops Boards just to see what it’s like and it totally has this problem. Each work item type has a completely different set of states and it’s this huge, unnecessary cognitive load. The places I've worked that use it mostly just use Story and Bug. Maybe the Epic (or whatever that trophy icon one is) to collect Stories, but devs don't really change the status of an Epic.
|
|
#
?
Apr 11, 2019 14:06
|
|
|
Munkeymon posted:The places I've worked that use it mostly just use Story and Bug. Maybe the Epic (or whatever that trophy icon one is) to collect Stories, but devs don't really change the status of an Epic. Thanks, maybe I’ll try it that way and see how it goes. The whole thing screams of “Aha, this will be the work tracker that’s finally better than Jira!” And surprise: it’s not.
|
|
#
?
Apr 11, 2019 14:11
|
|
|
raminasi posted:I started playing around with Azure Devops Boards just to see what it’s like and it totally has this problem. Each work item type has a completely different set of states and it’s this huge, unnecessary cognitive load. Try working in the board view. The states are tailored to the purpose of the work item, and are consistent across a board. Requirements (PBIs/features/epics) go on the backlog board, tasks go on the sprint/iteration level task board. Bugs are a weird case because they can be treated as requirements OR as tasks (depending on whether you use the Scrum or Agile template / how you configure a given team).
|
|
#
?
Apr 11, 2019 14:16
|
|
|
raminasi posted:it’s not. Eh, having used both I prefer ADO
|
|
#
?
Apr 11, 2019 14:18
|
|
|
Munkeymon posted:The places I've worked that use it mostly just use Story and Bug. Maybe the Epic (or whatever that trophy icon one is) to collect Stories, but devs don't really change the status of an Epic. Yeah, the only thing that anyone should care about day-to-day outside of sprint planning / backlog grooming is user story, task, and bug. The feature/epic mapping to user story shouldn't really be relevant. Devs look at the task board for the sprint, see a bunch of user stories broken down into tasks, and start working on tasks. When the tasks are done, the story moves to the "done" column. Then someone starts customizing and adding additional states and state transitions and backlog columns and everything sucks and is a mess. The out-of-the-box configuration is pretty lightweight.
|
|
#
?
Apr 11, 2019 14:25
|
|
|
Protocol7 posted:
Why aren’t you all just reverting the big PR and having the dev split it into 17 separate ones that each go through CR?
|
|
#
?
Apr 11, 2019 15:11
|
|
|
bergeoisie posted:Why aren’t you all just reverting the big PR and having the dev split it into 17 separate ones that each go through CR? Great question. Probably a better question for the three architects and one dev manager who reviewed the PR.
|
|
#
?
Apr 11, 2019 15:14
|
|
|
raminasi posted:Thanks, maybe I’ll try it that way and see how it goes. The whole thing screams of “Aha, this will be the work tracker that’s finally better than Jira!” And surprise: it’s not. We're not gonna get a better Jira until we get something better than Scrum. Jira is peak Scrum.
|
|
#
?
Apr 11, 2019 15:26
|
|
|
lifg posted:We're not gonna get a better Jira until we get something better than Scrum. Jira is peak Scrum. Almost anything is better than Scrum, so that shouldn’t be much of a barrier.
|
|
#
?
Apr 11, 2019 15:34
|
|
|
Subjunctive posted:Almost anything is better than Scrum, so that shouldn’t be much of a barrier. That is like saying that human poo poo is so much better than horse manure, so we should totally eat human poo poo. All work methods start as reasonable idea, wholesome foods if you like, before they are eaten up, digested and shat out by whatever consultant gets their grubby hands on it.
|
|
#
?
Apr 11, 2019 16:38
|
|
|
Keetron posted:That is like saying that human poo poo is so much better than horse manure, so we should totally eat human poo poo. Exactly this. I feel like the ideas are great on paper, but are never executed well enough to fully reap the benefits of the methodology. For a good example of a big pile of consultant poo poo, see: SAFe.
|
|
#
?
Apr 11, 2019 16:48
|
|
|
The Waterfall Defender has logged on kidding I hope 
|
|
#
?
Apr 11, 2019 16:49
|
|
|
Munkeymon posted:The Waterfall Defender has logged on Me? Certainly not!
|
|
#
?
Apr 11, 2019 23:51
|
|
|
Munkeymon posted:The Waterfall Defender has logged on for 500 person 5 year projects there's no deliverables or iteration possible in 2 week time frames, the premise of agile surfacing these things to some customer breaks down. on projects with other disciplines (ME/EE) their flows are based on prototypes of various sophistications (staged breadboards with specific goals, then the typical EVT/DVT/PVT cycle on the way to mass production) with the only quick-spin-iteration activities only applying to subsystems or individual parts, waterfall's just fine for the big picture.
|
|
#
?
Apr 12, 2019 01:06
|
|
|
lifg posted:We're not gonna get a better Jira until we get something better than Scrum. Jira is peak Scrum. having code changes directly linked to work items in ADO is really rad though.
|
|
#
?
Apr 12, 2019 03:19
|
|
|
JawnV6 posted:for 500 person 5 year projects there's no deliverables or iteration possible in 2 week time frames Good, because these projects shouldn't exist and are doomed to fail. "A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system"
|
|
#
?
Apr 12, 2019 07:27
|
|
|
Messyass posted:Good, because these projects shouldn't exist and are doomed to fail. This is actually a very good point that everyone should understand. Just beware of consultants cargo-culting about MVPs.
|
|
#
?
Apr 12, 2019 11:10
|
|
|
Messyass posted:Good, because these projects shouldn't exist and are doomed to fail. guess we shouldn’t build aircraft then oh well
|
|
#
?
Apr 12, 2019 12:54
|
|
|
TwoDice posted:guess we shouldn’t build aircraft then Anyway, here's a talk about kanban at Airbus https://www.youtube.com/watch?v=e_4YV5I2l0Q
|
|
#
?
Apr 12, 2019 13:01
|
|
|
TwoDice posted:guess we shouldn’t build aircraft then This is about designing, not about building, and it's not like Aircraft design hasn't evolved over time. The Wright brothers didn't try to design a 787. But sure, there are always exceptions. Something like the Large Hadron Collider, for which a simpler/smaller version isn't even possible... Gotta respect that.
|
|
#
?
Apr 12, 2019 14:48
|
|
|
|
| # ? May 27, 2024 07:23 |
|
|
JawnV6 posted:yo i gotchu Touching hardware? Eew! Gross! For real, though, I get that that's a whole different world and don't think the way I make enterprise fart apps that are so divorced from physical reality that we're billed by the infrastructure provider by the Platonic Compute Unit doesn't necessarily apply to the process real engineers use to design and build, say, a medical robot.
|
|
#
?
Apr 12, 2019 14:55
|
|