|
smackfu posted:I feel like we are pretty bad at breaking features into stories and could use some advice. We own the full stack and generally start with a UX design for the feature. This usually gets turned into one story per screen, which makes sense from a product owner perspective. Down this road lies a world of 50 and 80 point stories that takes weeks and weeks to complete. You need to, if at all possible, break down each screen story to as small components as possible. Does the screen contain elements? Super each element is a story. Where does the data come from that feeds this screen? More stories
|
#
?
May 31, 2022 19:50
|
|
|
|
| # ? May 13, 2024 04:08 |
|
|
Daviclond posted:You can get quite creative with breaking down back-end stories, one of my favourite tricks is to implement a dummy endpoint that returns a hardcoded response entity and split off the "real" work to a separate ticket or two. This unblocks the front-end (it can hit the API) and you can do the real back-end in parallel. Getting used to delivering small, quick, incremental tickets is a cultural thing that's worth the effort of cultivating. This is the way
|
|
#
?
May 31, 2022 19:51
|
|
|
I really like the term "enabler story". It fits perfectly with the collection of bad, destructive habits that is scrum/agile.
|
|
#
?
May 31, 2022 20:48
|
|
|
This is somewhat a rant but also a question... The company I work for, a few years ago, signed a contract to use another company's product - which included a bunch of libraries, on-prem software, lots of stuff. We used all that stuff, along with our existing and new stuff, and made it into a product, with tools and pipelines surrounding their stuff. Let's call the other company/product "ForwardFriend" and our product "Jubilee". A few years later, "Jubilee" has failed, we've moved clients to other stuff, etc. We don't use any ForwardFriend in any of our products, but there are still like, small references to it in various places. Specifically we have another product that reuses some CSS from the old Jubilee days, and some class names include "ff" - since they originally were used with the ForwardFriend templates or something. Here's where I'm frazzled. Apparently our final contract with ForwardFriend ends soon, and legal has determined we can't be using any of their code any longer (totally fair). And also that we need to remove anything with "ff". And also that we need to remove all of it from the entire git history, not just current stuff. Is this... crazy? Or standard? It just seems like a lot of work for no loving reason.
|
|
#
?
Jun 22, 2022 03:01
|
|
|
It sounds like they don’t know how GIT works. Are they expecting you to change every reference to the word office to oice as well?
|
|
#
?
Jun 22, 2022 03:08
|
|
|
Trapick posted:also that we need to remove anything with "ff". And also that we need to remove all of it from the entire git history, not just current stuff. this is absolutely ludicrous, and therefore certain to happen. If you regularly do any code archeology (patching old releases etc) it's going to be a nightmare.
|
|
#
?
Jun 22, 2022 03:15
|
|
|
BFG Repo-Cleaner is a relatively user-friendly tool for nuking stuff from your git history. Deleting all of the files from the vendor is quite easy. Deleting parts of files if they aren't nicely isolated like that is going to be much more of a pain. Renaming things and having the end result still build will be a gigantic pain, but depending on how important the leftover vendor stuff is to your product building the old versions might just never have been on the table to begin with. Getting everyone to delete their old local copies of the repo is a problem for legal and not something with a technical solution. BigPaddy posted:It sounds like they don’t know how GIT works. Are they expecting you to change every reference to the word office to oice as well? How git works is irrelevant. If you are no longer legally permitted to have copies of something (and not just merely no longer use it), it doesn't matter where those copies are.
|
|
#
?
Jun 22, 2022 03:41
|
|
|
BigPaddy posted:It sounds like they don’t know how GIT works. Are they expecting you to change every reference to the word office to oice as well? This is hilarious because the request shows they understand how git, or more likely version control, works. Legal doesn't want to get sued for the company having copies that it's not permitted to have even if the location of the copies is buried in history. This is probably something I would expect Legal to do even if you can technically keep it,, but not use it because it would be a disaster if they needed to defend against copying it. Edit: beaten by a bunch asur fucked around with this message at 03:59 on Jun 22, 2022 |
|
#
?
Jun 22, 2022 03:51
|
|
|
Plorkyeran posted:BFG Repo-Cleaner is a relatively user-friendly tool for nuking stuff from your git history. Deleting all of the files from the vendor is quite easy. Deleting parts of files if they aren't nicely isolated like that is going to be much more of a pain. Renaming things and having the end result still build will be a gigantic pain, but depending on how important the leftover vendor stuff is to your product building the old versions might just never have been on the table to begin with. I've been using filter-repo more than bfg lately -- it's as fast or faster and better supports targeting specific files or directories. But yeah, either of those will let you eliminate stuff from the repo's history. It will require everyone to completely stop working and re-clone the repo afterwards and may break existing PRs depending on the hosting platform, though.
|
|
#
?
Jun 22, 2022 03:53
|
|
|
Thanks for the tips on filter-repo and BFG Repo-Cleaner, they look more promising than the "nuke it all from orbit" approach we were talking about so far. As for removing files/libraries/etc. that part makes a lot of sense to me. I think we were smart enough not to commit that stuff directly, generally, and just import the artifacts at build time. But apparently any reference at all is verboten, thus anything ff-.*|.*-ff-.*|.*-ff needs to be renamed. Fun. Fun fun fun.
|
|
#
?
Jun 22, 2022 04:34
|
|
|
Trapick posted:But apparently any reference at all is verboten, thus anything ff-.*|.*-ff-.*|.*-ff needs to be renamed. Fun. Fun fun fun. Ah yes, compliance theater. I was going through that with a customer who wants elaborate auditing built into software while vehemently resisting the idea of zero privilege as the default. "Let anyone do anything, we just want to be able to see if they did anything bad. It's for our auditors!" It's like having a video camera pointing directly at the box of oily rags next to the furnace. It won't stop the house from burning down but you'll get to see EXACTLY how it happened.
|
|
#
?
Jun 22, 2022 05:07
|
|
|
Trapick posted:Thanks for the tips on filter-repo and BFG Repo-Cleaner, they look more promising than the "nuke it all from orbit" approach we were talking about so far. Have you had enough conversations with Legal to be sure that this is a requirement? In my experience, working with Legal is just like working with Product except that Legal is scarier and throws out a lot of threats (it's part of their job). When they say "remove all instances of 'ff'" that's just the opening request. Not only that, if you do it right away they'll mentally note that this is a trivial request for you and in make similar requests in the future. I think you'd want to push back: how long will this operation take. What's the cost to the company of doing this work (your manager and PM should be able to help here)? Legal has an estimate of the cost to get sued, so you want to provide an estimate of the cost to not get sued. Then you'll want to talk to them about how "ff" in code doesn't mean much. Maybe grep the Linux kernel and say "here's some clearly-unrelated code and it has 2000 instances of 'ff' so you should be about to defend our 20 instances in court."
|
|
#
?
Jun 22, 2022 12:37
|
|
|
We’ve done similar things when open sourcing repos at work. Clean up the code first then start from a new initial commit. Yes you lose the history but otherwise it’s just effort.
|
|
#
?
Jun 22, 2022 12:50
|
|
|
Mniot posted:Have you had enough conversations with Legal to be sure that this is a requirement? Yeah, it's worth pushing back a bit. Don't be "I refuse to do this stupid thing" or anything along those lines, but realize that their initial request is probably a list of everything that'd be legally useful, not everything that's legally required. If they aren't willing to yield at all, then just keep in mind that the goal here is to produce something that is more useful for you than nuking the history entirely would be. If your choices are a fresh git repo with no history, git history full of clbuttic due to some naive find/replace, and 6 months working on producing as good of history as possible (that still doesn't build since you don't have the vendor component?), clbuttic might be the right choice.
|
|
#
?
Jun 22, 2022 18:06
|
|
|
I'm a few steps away from legal, but yeah we've got some people pushing back/getting clarification. Definitely going to be a fun week.
|
|
#
?
Jun 22, 2022 19:28
|
|
|
I think I asked a few years ago but I'm gonna ask again: how do you all feel about monorepos? My org has a big fat Rails back-end, as well as 5-10 different React front-ends, anda couple different odds n ends projects (terraform config, socket server, etc.). So far every project has lived in its own repo, but we're starting a push to unify design elements between the front-ends and I'm wondering if it's time to reach for something like Turborepo or Nx or even just putting all the front-ends together and figuring out Yarn workspaces. One thing I've noticed when researching some of the popular monorepo packages is they presume that everything in the repo is a JS/TS project, and also they presume that you want to build and deploy everything at the same time. Neither of these things is really true. As much as I dream every day about replacing our Rails stuff with Typescript I think we're stuck with what we've got. Anyway, anyone have any thoughts on this stuff? I know a lot of big orgs have massive monorepos but I don't just want to blindly follow that.
|
|
#
?
Jul 7, 2022 16:41
|
|
|
It's apparently good, but I have never seen a good one.
|
|
#
?
Jul 7, 2022 16:53
|
|
|
Monorepos can work well provided you have strong tooling to handle building/versioning/incremental changes to specific artifacts/etc. Working in monorepos without good tooling can be a miserable experience, especially as the codebase grows.
|
|
#
?
Jul 7, 2022 17:15
|
|
|
It's great when people throw their hands up at how lovely the tooling is, at multiple levels in the organization, and then you end up with docker in docker in docker in...
|
|
#
?
Jul 7, 2022 17:18
|
|
|
Is your codebase actually so large that it would be a problem if everyone just checked out all the code and always pulled down the latest changes to everything? Is it going to grow to a size where it will become a problem in the next year? Because if not, you don't really need a "monorepo package" at all - fundamentally you can just stick your different projects in different folders in the same repository and it will work for you. Anything you want to layer on top of that (like shared build caching) is an optional extra that you can do if you think it will add sufficient value to justify the time you spend on it.
|
|
#
?
Jul 7, 2022 17:22
|
|
|
Jabor posted:Is your codebase actually so large that it would be a problem if everyone just checked out all the code and always pulled down the latest changes to everything? Is it going to grow to a size where it will become a problem in the next year? Well currently "everyone" is just me so really any change is going to be primarily about making my life easier with the secondary goal of maybe making onboarding a second and third developer easier down the road if we decide to scale back up. Our CTO left a couple months ago which means it's my castle now and I'd really just like to reduce the overall jank in our processes and get things more organized. We also have a new UX designer starting soon which is why one of the problems I'm looking at solving in the short term is unification of our front-end components. Being able to change <Button /> or <TextInput /> in one place and have it reflected across our apps would be nice, or just having one shared Tailwind configuration instead of having to keep a bunch of them somewhat in sync. Maybe that's a problem that can be solved without switching to a monorepo, but what I don't really want to deal with is having to like publish a "myorg-ui" private npm package every time I need to make a change to one of our core components for whatever project I'm working on.
|
|
#
?
Jul 7, 2022 18:40
|
|
|
We're building a Rails monorepo and using packwerk. I, personally, don't like it because our company hasn't historically demonstrated any discipline over consistent code organization or separation of concerns, and it's not looking like we're getting any better as we move away from the original monolith. I like having microservices, but it's mostly because I've had the opportunity to work in well defined application spaces as opposed to working in something where it's hard to determine where business logic should go.
|
|
#
?
Jul 7, 2022 20:56
|
|
|
Is there a reason to want to have things split into a bunch of repos? It sounds like you're trying to unify the various front-ends into a single project where you work on all of them at once, and at that point putting them all in the same repo isn't really a monorepo per se.
|
|
#
?
Jul 7, 2022 21:16
|
|
|
Plorkyeran posted:Is there a reason to want to have things split into a bunch of repos? It sounds like you're trying to unify the various front-ends into a single project where you work on all of them at once, and at that point putting them all in the same repo isn't really a monorepo per se. That's not quite it, they're still separate projects that are built and deployed separately. Some apps go months without being updated if there's no need to. What I want to unify is more like a set of common components that would be shared across those apps, as well as maybe some util functions, custom react hooks that I don't want to publish, etc.
|
|
#
?
Jul 7, 2022 21:25
|
|
|
Things that will need to change at the same time should be in the same repository. Monorepo is a "safe" pattern, admitting that you can't rule out the possibility of any two given pieces needing to be changed atomically, so you might as well build in the possibility from the beginning.
|
|
#
?
Jul 7, 2022 22:48
|
|
|
thotsky posted:It's apparently good, but I have never seen a good one. We use a pretty good one, but there's some impressive investment in tooling around it behind the scenes. I've rewritten this several times, but each time I basically just say "a monorepo will probably not help to solve the problem you're actually trying to solve"
|
|
#
?
Jul 8, 2022 00:02
|
|
|
yeah google does it by throwing a shitload of "geniuses" at the tooling problems that inevitably crop up, blithely tossing out "its a safe pattern" without mentioning the other half of the tradeoffs seems irresponsible at best
|
|
#
?
Jul 8, 2022 00:12
|
|
|
JawnV6 posted:yeah google does it by throwing a shitload of "geniuses" at the tooling problems that inevitably crop up, blithely tossing out "its a safe pattern" without mentioning the other half of the tradeoffs seems irresponsible at best My dude you need to calm down, Reader has been turned off for a long time now, let it go. And, for what it's worth, I'm actually very happy with the end result around the source code situation, it's leaps and bounds better and beyond what I dealt with in other large companies. It's also very much solutions for very large companies with very large company / codebase problems, which is why I suggested that maybe a monorepo is not the way to solve the actual problem.
|
|
#
?
Jul 8, 2022 01:18
|
|
|
all this mirrors what i've heard elsewhere, which is that a monorepo can work if you're willing to invest in and dedicate a team of devs to building out tooling and suchVolmarias posted:My dude you need to calm down, Reader has been turned off for a long time now, let it go. absolutely loving not
|
|
#
?
Jul 8, 2022 03:25
|
|
|
If this is a one-person gig then stuffing everything in one repo is just the obvious way to go. The scalability issues that people have with monorepos will just not be a problem for you at all. Splitting into multiple repositories is the thing you do when you grow too big for a single repo to work easily, but are not big enough that you want to devote people to making a monorepo scale.
|
|
#
?
Jul 8, 2022 05:17
|
|
|
Volmarias posted:This specific scenario is where the metaphor breaks down, and why I don't (and others don't) use user stories for things. User stories are excellent for mainly visual content, with minor backend processing, but they fall down for things like "As a driver, I want the car to start when I use the ignition" which is a button press to the user and an absolute ton more behind the scenes. Back a bit but man this gave me flashbacks to a previous gig where they absolutely would not consider thinking about systems outside the lens of user stories, and refuse to do (or allow time for) actual analysis / design / planning of the system that's supposed to fulfil them. So you'd end up with specs containing user stories that implied huge non-user-facing features and bafflement when suggesting that you might need to build things outside that concept. Very much one of those tools that people latch onto. I am a big fan of user stories as a chunk of the overall design where you use them to validate the actual system you're going to build, but then you actually design things coherently and use the stories to check up that your design actually achieves useful things. The other big failure is when you look at your tickets as a whole and realise that these six different stories are actually one piece of work, and giving them to a dev one at a time was a disaster.
|
|
#
?
Jul 8, 2022 08:12
|
|
|
The thing to remember is that there's a middle ground between a monorepo and lots of scattered repos. Sometimes it might make sense to merge two repos into one because they're tightly linked enough, but not to consolidate any further. You can even do that as an experiment to see what you gain or lose in terms of efficiency. Same deal when splitting a monolith down into separate packages. You don't have to scatter the whole thing to the four winds in one go, you can just split out one chunk of code to be its own thing, and that might be enough. The reason I advise some caution here is that the engineering tradeoffs here can be huge. Neither is a slam-dunk easy decision. No reason to jump in with both feet if you can avoid it.
|
|
#
?
Jul 8, 2022 09:04
|
|
|
It depend a lot on the size of the team(s) that will use to dev / package / release / operate the software. It’s easier to split access rights and isolate triggers and actions when everything is separated but maybe it might be easier to glue everything together if there is a single repo, keep in mind that the way to code is built in CI/CD pipeline is very often a mirror of how the repos are separated. Imho just like the code being written, how the code is stored, built, packaged and deployed should reflect the organization structure that own it.
|
|
#
?
Jul 8, 2022 12:48
|
|
|
I think when our designer starts we'll have a chat about what our goals are for the user facing aspects of our products and if it really is "let's unify the hell out of this" then putting at least those projects in a monorepo probably makes sense. Speaking of microservices I'd certainly love to shave off some pieces of our Rails backend monolith but since everything is glued to the central MySQL database anyway the idea feels extremely fraught. I think what I actually want is to still have a backend monolith but for it to not be Rails. That's probably some grass-is-greener thinking but even though I have like 15 years of Rails experience I would just be much happier working in Typescript.
|
|
#
?
Jul 8, 2022 13:07
|
|
|
My rule of thumb has always been that a repository should contain a single releasable unit. That's not a perfect solution but it seems to work pretty well for the projects I've been on.
|
|
#
?
Jul 8, 2022 14:00
|
|
|
Working within the Big G monorepo has been one of the best experiences of my career. Everything building and linking and marching forward together in unison forever. Some smart guy mucks with core libraries the entire world breaks that poo poo gets detected and rolled back faster than you can imagine. Would recommend.
|
|
#
?
Jul 8, 2022 19:50
|
|
|
Paolomania posted:Working within the Big G monorepo has been one of the best experiences of my career. Everything building and linking and marching forward together in unison forever. Some smart guy mucks with core libraries the entire world breaks that poo poo gets detected and rolled back faster than you can imagine. Would recommend. Don’t extrapolate from Google's implementation and assume other teams will have the automation and testing discipline to achieve similar results. I've seen many orgs try to pull off a Google style monorepo and it's just "Some smart guy mucks with core libraries the entire world breaks."
|
|
#
?
Jul 8, 2022 20:15
|
|
|
Heh, I bet it’s like a virus that infects companies that hire ex-Googlers.
|
|
#
?
Jul 8, 2022 21:19
|
|
|
smackfu posted:Heh, I bet it’s like a virus that infects companies that hire ex-Googlers. Like Go
|
|
#
?
Jul 8, 2022 23:45
|
|
|
|
| # ? May 13, 2024 04:08 |
|
|
What do you call this mess they have where the android git repos needed a utility just to manage them all https://source.android.com/setup/build/downloading
|
|
#
?
Jul 9, 2022 01:16
|
|
