|
There are tons of ways but doing it via cron seems pretty silly? You should definitely have an automated way to deploy to servers but it should be something that happens by a person pushing a button or by some sort of trigger or event that isn't "every x time".
|
#
¿
Nov 30, 2015 15:52
|
|
|
|
| # ¿ Apr 27, 2024 11:11 |
|
|
I suppose you could hack together a pipeline where github being down means you literally cannot deploy to your servers. You'd have to try really hard, though, and make a lot of really bad decisions. I'd still consider it a net gain because then you could fire whichever idiot came up with it.
|
|
#
¿
Nov 30, 2015 20:47
|
|
|
I thought capistrano was pretty poo poo to be honest. My current org uses it, for whatever reason the devops team doesn't own the deploy mechanism, and they're pretty much constantly fighting with it. I'm sure there's some functionality there that makes capistrano not "ansible, except lovely" but whatever it is, it's not seeing any use here. But there are plenty of ways to autoscale "check code out of version control". It's such a solved problem that it's almost not worth discussing without some more context.
|
|
#
¿
Dec 2, 2015 06:08
|
|
|
The rule there is usually that every commit of the target branch should be deployable, and yeah that is absolutely reasonable to request. If you're squashing or otherwise merging such that in the target branch HEAD is all of your changes and HEAD~1 is none of your changes, no that's totally unreasonable.
|
|
#
¿
Mar 10, 2021 18:15
|
|
|
HappyHippo posted:I mean the whole discussion started with "1300 lines is too long." And when people push back with "sometimes that functionality is related" they get replies like this: That wasn't my read of it, personally. It's absolutely important to break down problems into smaller problems that can be understood separately, not doing this is totally just writing bad code. There wasn't anything in the post that implied, to me, that these decoupled sub-problems need to be in different files. They should totally go in the same file. e: the never nesting loops guy, and the rest of your examples, are totally deranged, though. 12 rats tied together fucked around with this message at 19:42 on Mar 10, 2021 |
|
#
¿
Mar 10, 2021 19:40
|
|
|
Agreed, and I'd also say that it varies based on problem domain. I worked on a game server where the code responsible for "what happens when a player uses an ability" is basically a series of 20,000 LoC switch case statements. I absolutely would not rewrite it any other way, but the structure is extremely simple to understand for anyone doing work on the game because everyone arrives at this file/ these statements with the mindset of "I need to adjust what happens when skill id is 1234, I will now search for skill id 1234". In an alternate domain this pattern would result in the worst MVC app, for example, that it is possible to create.
|
|
#
¿
Mar 10, 2021 20:05
|
|
|
There are actual metrics you can use to evaluate code and domain designs, but yeah "cleanliness" isn't really one of them. I usually lean towards looking at cyclomatic complexity and evaluating SAGE -- specialization, afference, generalization, efference.
|
|
#
¿
Mar 11, 2021 18:46
|
|
|
Canine Blues Arooo posted:"The more you enforce 'academic' coding standards on a project, the less output you'll get", but I'm increasingly convinced that is indeed the case. My experience re: this concept and this wider discussion is that there is definitely (obviously) a happy medium between "I am free to do whatever I want at work so long as I personally conceive it to be productive" and "as a rule, I viciously attack all work I don't personally produce", but also, trying to discuss where that happy medium is located is totally pointless without a formalized and adhered to design process. The best org I've worked in, in this perspective, definitely cultivated a culture of active peer review and critique. We also had consensus based standards so the critique was always "This implementation could more closely follow X design principle (link to document explaining it) by making these changes" or "Since we adhere to YAGNI, it is better if you don't pre-implement this interface and just take the naive approach for now". Part of even being able to produce a design that is peer reviewed involved participating in an onboarding process and first having reviewed another design yourself, which you did with your mentor and they would explain the process, go over the standards, etc. The more potentially heated/fundamental discussions (ex: ORM or not) happened on a different cadence, in a different forum, and with a different set of participants including engineering leadership. Litigating nested list comprehension vs nested for loop in pull request comments is a negligent waste of your own time as well as the the time of your coworkers. That design review could even be perceived as either polite or impolite is also an indicator that the design process itself is flawed.
|
|
#
¿
Apr 4, 2021 05:24
|
|
|
smackfu posted:Giving a ton of nitpick comments isn’t really addressing the root cause, just wasting the reviewers time. Agreed, nitpick comments can be really exhausting to deal with since you're putting a lot of responsibility onto the contributor and still consuming as much of your time as is possible in this process for filing them. IMO: Never nitpick, there is either a code style issue or there is not. Highlight the errant code and provide either mention of, or a direct link to, the style guide that mandates an alternative approach. If there is no style guide, I wouldn't waste my time trying to create an implied one in pull request comments, there are better forums for that.
|
|
#
¿
Apr 12, 2021 17:58
|
|
|
What I'm looking to give/receive from code review is not "12 rats says this looks good to him", it's "12 rats certifies that this code meets the standards and guidelines set out in <team documentation> to the best of his knowledge". My "I think this pattern is a bad idea, and the codebase should be structured in this way" feelings go to meetings where we discuss and maintain the style guide. Code review is decoupled from that process so that we can all do it faster and more predictably. If you work in a shop under a heavily compliance burden you will also often find satellite processes orbiting code review, in particular, I used to have to check a box saying "I thought about these changes as they relate to <each letter in STRIDE threat model> and found no issue with them". If I were clogging that process up with comments about, for example, nested for loop vs nested list comprehension, I would be spending too long in code review which is a double offense in that it wastes my own time as well as the time of the contributor. It's much easier to just copy paste "All strings should be double quoted" out of the guide on my pull request comments and then move on, even if I don't necessarily agree with always using double quotes or care one way or the other. 12 rats tied together fucked around with this message at 18:13 on Apr 12, 2021 |
|
#
¿
Apr 12, 2021 18:11
|
|
|
JehovahsWetness posted:Ideally this kind of static analysis / linting should be handled by CI/CD so it's all taken care of before a human has to even look at a PR. Having a robot say nahhhh doesn't hurt anybody's feelings and it's consistent. Yeah, that's kind of what I was (obliquely) getting at: style nitpicks are in the linter (fed by configuration generated from documentation). They'll never make it to PR unless the contributor is appending "ignore this" annotations to their code or if they found an incantation that confused the linter, both of which are real issues with concrete and definable paths forward instead of "nitpick, you can ignore this, which means you now have to decide whether or not to ignore this".
|
|
#
¿
Apr 12, 2021 19:58
|
|
|
I liked the emoji guide linked earlier because it had an explicit "usually better left unsaid" note for the nitpick-pickaxe emoji classification. It's not the end of the world if you do it, there is absolutely room for it on everyone's plate, but it's better if you don't.
|
|
#
¿
Apr 13, 2021 07:19
|
|
|
I worked at a place where we did pure kanban in trello and it was fine. Individual contributors don't need any of the features in JIRA or Azure DevOps, IME those mostly exist as a stand-in for having an actual project management process. Later on that place got a bunch of investment money, hired a bunch of project managers, and bought a bunch of JIRA bullshit but we kept doing pure kanban and it was still fine, just significantly worse for no reason because JIRA is a bloated piece of trash even with factory default settings.
|
|
#
¿
May 12, 2021 16:59
|
|
|
Yes there are ~3 promises made while doing "pure kanban" which isn't really a thing, but I feel like it needs the descriptor because the term kanban has been hijacked to also mean "the thing you click on to look at your tasks in jira". The promises are: The backlog is sorted such that the top issues are the most important issues. Individual contributors will pull the top issue, self assign it, and move it into "in progress". Individual contributors will not exceed the limit on the "in progress" column. For an IC, you work one or two issues at at a time, depending on what your team agrees on. You pull either the top issue from the "to do" column or you pull something you had previously shelved in the "blocked" column. You can work with your coworkers and manager to decide if you should pull something they had shelved in the blocked column or the top issue. The one vs two issue distinction generally depends on how long it takes to do code review and to actually merge and ship your changes. Teams with longer integration cycles had extra columns for things like "awaiting code review", "running in staging", "awaiting production deploy", etc. For two extreme points of comparison the devops team had todo, in progress, done, and the data platforms team had columns for "waiting for next week's ETL job to validate" and similar. For the team lead and the PM, you make sure that the backlog is sorted. You can re-sort the backlog at any time. If I had to describe it in a single phrase, it's basically lazy-loaded scrum. You do mostly the same things, for mostly the same reasons, and it produces mostly the same value, but you don't need to do any of the meetings and the focus areas are wholly decoupled from each other so they can both run at a higher level of accuracy. You only need to discuss whether or not to pull the top issue vs pulling a shelved issue when it comes up, and the only people who need to discuss it are the IC doing the pulling and the IC who previously shelved an issue. You never need to cost anything, you can run whatever reports and assign whatever arbitrary values you like to aspects of the workflow at any time, and you can use any tool for it instead of needing to find the right report type in JIRA or whatever.
|
|
#
¿
May 12, 2021 19:20
|
|
|
It's (kanban) is great for ops teams and other interrupt-heavy, external-dependency laden workflows because you can just be blocked by 2 month lead time on getting a server shipped and move the ticket for that into the blocked column for 2 months. That's not against the rules, you don't have to "spill to the next sprint" every 2 weeks for the next 8 weeks or whatever, it just sits there as a piece of work in progress that is blocked until it is no longer blocked. The entire point of the workflow is to identify things that are doing this and make them visible to project management, so they can actually project manage, instead of being JIRA report touchers, so it being a big ugly red box in your blocked column is a feature of the process.
|
|
#
¿
May 12, 2021 20:49
|
|
|
Writing the platform first would break "you aren't gonna need it" which is something I usually try to stick to. You'll almost certainly get it wrong, or not fit your requirements exactly, and then you pay the cost of initial implementation plus the cost of carry until the codebase is actually needs-fitting (which is not actually guaranteed to ever happen -- a poorly built platform could just be an unbounded cost stretching forever into the future). "Building the platform first" is a bad idea about 99% of the time, however, writing platform-capable code is just being a good developer. e: of the two disaster scenarios here, "everyone builds their own ladder" vs "multiple competing platforms", the second is also much worse. It's much easier to find emergent patterns that are worthy of platforming from those ladders than it is to deprecate one platform in favor of another. 12 rats tied together fucked around with this message at 17:44 on May 14, 2021 |
|
#
¿
May 14, 2021 17:40
|
|
|
chglcu posted:Also, and this may just be me, but I actually appreciate when the reviewee ask questions when they don't understand or pushes back a bit when they don't agree with a suggestion.
|
|
#
¿
May 26, 2021 16:05
|
|
|
Ghost of Reagan Past posted:So I'm the principal (backend) engineer at a really small little company launching a product, and I've been tasked/picked up the devops/deployment tasks. I've got the basics containerized and our deploy pipeline working (for a variety of reasons this is the best approach for us right now), but it's obviously very rudimentary and I'm kicking some cans down the road (things we don't need to deal with today, genuinely). But does anyone have a good watch/read on Docker (or really, containerization and devops generally...not wedded to Docker, but again for a variety of reasons it's the best approach for us today) best practices? I just want to make sure I don't write us into too many corners that'll be a pain to get us out of. If you haven't already, I would recommend reading up about 12 factor apps. It doesn't cover everything, but it's one of the best single-source resources for modern applications / "devops". Containers are really more of an implementation detail than they are a fundamental technology change, but you should be able to get a good handle on most of your future questions about using docker in prod by googling "how do I do <thing from 12 factor> in docker?".
|
|
#
¿
May 29, 2021 00:59
|
|
|
The toyota stuff actually rules but the cottage industry that has grown up around it sucks complete rear end. Kanban is the only workflow system that even kind of works for ops. Nobody can read about Kaizen and be like "I disagree with this fundamentally". Absolutely do not hire consultants for "implementing" either.
|
|
#
¿
Sep 16, 2021 21:37
|
|
|
100% of the time you should record and play a video instead of doing a live demo. Bonus points for annotating the video and editing out waiting periods.
|
|
#
¿
Sep 27, 2021 23:01
|
|
|
Ape Fist posted:Every time I've encountered the word 'Microservices' and 'Docker' together I immediately get depressed because you know this poo poo is going to be loving Chaos. In theory good, in practice extremely upsetting. The theory is almost always bad too but nobody takes the time to think about it hard enough to realize.
|
|
#
¿
Dec 20, 2021 17:29
|
|
|
I am loathe to continue this topic but I just want to reiterate that, lack of prescriptivity or no, "hard r" means a very specific thing in the USA and you should not use the phrase unless you know what it means and you intend to communicate exactly what it means to another person. If it's at all a question, best to just not use it at all.
|
|
#
¿
Feb 14, 2022 23:50
|
|
|
since everyone is remote now the best policy would be to let the employees keep them after their refresh period. saves IT a ton of work and makes the employees happy on hire and on refresh date i have never received old equipment for any job but if i got one now during the ongoing global supply chain fuckery i would not be too surprised
|
|
#
¿
Feb 24, 2022 01:56
|
|
|
BigPaddy posted:AWS is super opaque compared to Google Cloud or Azure. It just the interface but the documentation as well. Stuff that should take minutes can take hours because the docs are missing, out of date or just wrong. There is a reason why products like Terraform exist to make it less frustrating. That's interesting because I have pretty much the exact opposite opinion, including an opinion where I question why anyone would use terraform for AWS because it is strictly worse than the platform native comparison of CloudFormation, including and especially the documentation. Of the 3 major US providers AWS tends to have the best, most complete, and most up-to-date documentation for its core features. In my experience the only other provider even in the same league is Alibaba Cloud, but you're not likely to run into them unless you need to do business in China. In OP's case there are step-by-step instructions for performing that particular task through the web interface or the CLI. If you were to use CloudFormation instead, the AWS::EC2::Volume resource specification has detailed information about what the "size" property is, what its type is, and most importantly: what happens when you change it. After you publish a change to a volume you'll be presented with a cloudformation change set which includes explicit, detailed information about what is going to change, why it's changing, and what impact this will have on your resource (in this case, "No Interruption").
|
|
#
¿
Mar 15, 2022 22:33
|
|
|
Current employer has a "cameras on" policy and I simply do not follow because I don't give a poo poo, I will keep my camera off if I feel like it, and I extend this extremely basic courtesy to every other human on the planet.
|
|
#
¿
May 21, 2022 21:45
|
|
|
prom candy posted:Also let's say that the centrepiece of your backend is an SQL database that is the single source of truth for just about everything. Probably helps to start by noting that this is the true source of the monolith, rails really doesn't have anything to do with it. Breaking up the monolith is going to mean, mainly, breaking up these foreign key relationships and coming up with a less tightly-coupled database schema. If you change the service logic from rails to whatever new thing you want to work with more, but they both still depend on the "monolith of the row", it's now a distributed monolith which is way worse than it was before for no benefit.
|
|
#
¿
Aug 6, 2022 23:57
|
|
|
asur posted:I don't really agree that the base of the monolith is the data. If the data is in separate tables and you can have ACLs based on table, which I think SQL supports, then moving to separate dbs doesn't gain a lot in this situation and loses functionality. There are definitive reasons to break a database into multiple, but prom candy isn't giving any problems that would indicate his company is there yet. "Monolith" comes with a lot of implied context these days, but in the case I'm discussing, it absolutely stems from the data in the database. You can run a dozen different BE and FE technology stacks in front of the same models in the same database, sure, but then when you're running migrations every tech stack sees the update (and potentially the outage) immediately. That's still a monolith, it's just a way more complicated and brittle one for no benefit. I don't think a "code monolith" is a real thing, it seems like you're describing a call stack, which is not really related to application architectures. I do agree with you that OP seems like they just want to rewrite off of rails because they don't like it, which is fair, but not really a question of where rails falls on monolithic vs service oriented design. If this were my workplace I would implore OP to consider just writing a normal service, in ruby, and to use sorbet for static typing. This has the best path forward assuming that they get it right, and it has the least expensive path back into the monolith if the service boundary was not drawn properly and it ends up just being left join over HTTP.
|
|
#
¿
Aug 7, 2022 19:21
|
|
|
It's very common but it's not especially good, which is probably why a bunch of people (myself included) jumped out of the woodwork to issue warnings of various stripes. The big trouble spot is usually something like: if your service provides an HTTP GET, it's usually just going to end up as join-over-HTTP, because someone will write some "SomeModel's Foo attribute is the result of http get, my-service, /things/, whatever id". That's the distributed monolith. What happens when the service is down? or slow? Calls to this handler are unavailable now because we can't generate valid serializations of SomeModel. This means that anybody else who depended on us is now also down and we've officially stepped on the "cascading failure" rake. You can end up writing an incredible amount of defensive architecture (circuit breakers, dead letter queues, backoff timers, deadlines and deadline propagation, and so on) for a problem that really didn't need to exist in the first place. The benefit of monolithic design in this area is twofold: one, you don't require that everyone simulate an entire galaxy of HTTP APIs on their laptops with docker compose just to be able to run a test suite, and two, everything goes down for an upgrade at the exact same time, and it comes back up at the exact same time.
|
|
#
¿
Aug 8, 2022 20:12
|
|
|
prom candy posted:Thanks, this is good stuff. The services I'm thinking of are more like background jobs that run on a queue or are triggered by cron. We have a bunch of processes that are basically running 24/7 and I do wonder if I could save a bunch of money if I didn't have to spin up my entire Rails app for each one. We're a social media company so we do a lot of just getting stats from a user's profile and saving it in a DB so we can create charts for them, stuff like that. Just to be clear, my current employer has this particular footgun on full auto and it's going to make my work life measurably worse in the next 6-9 months, so, if I seemed like I was projecting a little I absolutely was. I think you've got it that "really and truly be cleanly separated" is the key, but unfortunately it's very hard, it (correctly factoring a system, or decomposing a system to fit new requirements) is probably the hardest problem in all of software engineering, IMO. It's easy to pull out "left join over HTTP" as a way to shoot down an idea, but I also want to be clear, a service that doesn't meaningfully interact with any other service is just an "app". Even if you did SOA/microservices perfectly and factored your subsystems and modules exactly correct, if you end up with 1 service that's still a monolith. All service architectures must react to other services (software that doesn't call other software is largely useless). I'm not an expert but to me, the sign for "there is potentially a clean break point here" is whether or not your service needs to perform a sql insert with data from another service. Like, if you're doordash, and you have table Orders in your monolith and then your "delivery service", which is a different web stack with its own postgres, needs to GET monolith/orders/order_id -> find a valid driver -> and then save an instance of DeliveryOrder which is an OrderId plus a DriverAssignment, and then you had a status updates service that queried both for push notifications/websocket events, that's bad. That's the distributed monolith again, "go and GET delivery/orders/1234", we're talking about data and we want the data that the "delivery service" "owns". There already exists an architectural term for "a place where data is", so (to be slightly pedantic) the delivery service doesn't really own any data, the delivery service is the behavior ("find a valid driver"). If you can cleanly cut your architecture at separation points between behavior domains, you will theoretically be able to create a good service. If your service is just a different database in disguise, that will usually be bad. In my experience, the main hint for whether or not a service has a clean separation point is how easy it is to test. If it's any more complicated than "a series of mock DriverRequests", it's probably a bad idea. If it needs a dependent service (which, again, is likely not a "service" but a database in disguise) running locally for tests, it's probably a bad idea, and so on.
|
|
#
¿
Aug 9, 2022 18:31
|
|
|
in kanban the estimation would come from your PM/lead and it would be based on historical data about how long it has taken to move a similar work item through the entire production chain in the past, where you might be tasked with grouping items of similar effort together, but you would never be asked how long it will take to complete TEAMNAME-1234 but, a key aspect of it is that the forecasting includes the entire production chain and all potential blocked states, which includes review from other people. e: the other key aspect of it is that is explicitly based on time, not some abstraction for level of effort that everyone at all stages converts into time implicitly in their heads 12 rats tied together fucked around with this message at 21:07 on Aug 9, 2022 |
|
#
¿
Aug 9, 2022 21:00
|
|
|
raminasi posted:Ok I'm having real trouble figuring out constructive communication in response to some stuff that a guy on my team does. I just had an quintessential exchange. Here was the existing code (please forgive any syntactic errors, they were just introduced by my obfuscation): The first thing is a bad pattern precisely because the 2nd thing always happens. Usually when the 2nd one shows up, I try to make them both disappear instead: can the code be structured so that neither is necessary, like can we just shove them in a `class ConfigApi`, for example. I find that this usually provokes a more useful line of thinking than "have you considered writing code that isn't bad", even if its very appropriate in this case.
|
|
#
¿
Dec 13, 2022 06:39
|
|
|
it's not a good book. read martin fowler stuff instead
|
|
#
¿
Feb 11, 2023 00:35
|
|
|
the best thing you can do for today's beginners is to have read these things yourself and to provide practical demonstration of their good parts with code review.
|
|
#
¿
Feb 11, 2023 17:25
|
|
|
if your employer is publicly traded or wants to be, they'll be firing a large chunk of people because the stock market rewards them for doing so, irrespective of whether or not that makes a lot of business sense if they aren't publicly traded but are accountable to the whims of venture capital they might be in a similar situation depending on which bloodsucking ghoul organization they've accepted money from
|
|
#
¿
Mar 13, 2023 22:13
|
|
|
i think i know what Big Tech Company you're at so this is entirely not an option for you, but ime the best experience in this area is to just stop doing scrum entirely sort the backlog so the topmost issues are the most important. communicate the expectation that your job as an IC is to pull the topmost issue you can work and work it until completion. you can have 1 issue in progress at any moment. if you pull an issue that can't be worked you put it in the "CantDo" column and your team lead repairs it and puts it back into "ToDo" this ends up being a large productivity booster for a variety of reasons. one of the best reasons is that the grooming and refinement rituals only happen on demand as needed (because someone pulled an issue they couldn't do, and moved it to CantDo with an explanation why). refinement and requirement seeking become async, which is good, because for split-focus teams the requirements are usually externally sourced anyway. it's a huge waste of money and motivation to have the entire team sitting on a call and agreeing that we need to follow up with someone who isn't here about ticket 123. nobody cares about that poo poo, nobody got a job in computers to fill out jira statuses. ICs are the constraint, so the project management system should largely serve them, and free up as much time as possible so that they can do their job which is to individually contribute.
|
|
#
¿
Apr 7, 2023 06:57
|
|
|
they equate velocity with time because velocity requires time to be intelligible. rates of change are inherently measurements of time, it's a reasonable thing to do. "points" is slightly better because it's easier to intuit that they don't fundamentally relate to time. they only practically relate to time because work/time is what everyone actually cares about and what the scrum rituals were supposed to eventually improve if you practiced them correctly. instead of doing a crazy mental gymnastics routine to invent a thing that is only a single step removed from what everyone actually cares about and wants to talk about, you should just adopt a project management framework that acknowledges work/time for what it is, and tries to maximize it.
|
|
#
¿
Apr 7, 2023 18:50
|
|
|
Aramoro posted:I would always urge against time based planning. For it to work you really need to know who is going to be doing each task when you estimate it, otherwise you've not really estimated anything. The second thing it does is introduce constant deadline pressure. For me I feel this is a really an unhealthy pressure to put on the team, I'd much rather have point commitment for the team to think about collective effort. Sure, but the problem is that everyone converts it to time based planning in their heads, because it's what actually matters. Regarding the deadlines, that's a fair point, and I didn't really elaborate on it because I was phone posting: this is what kanban is good at. There are no extra deadlines because the workflow is constant and performed continuously. There is no deadline pressure on ICs because you are limited to 1 WIP issue. The psychological impact of such a system is that you show up to work and you know what is expected of you (pull and work the issue at the top of the queue), every interaction you're supposed to have with the system is provided as a lever with an immediate and obvious impact (move to: "done", "cantdo", "blocked"). Because your WIP limit is 1, everything that would interfere with your ability to act as an IC is a conversation. Priorities changed at the latest SVP cringe meeting and you need to work a different issue? You put yours back into ToDo and leave some notes, and then your team lead re-sorts the tickets list once more so that the top issue is most important again. The result of performing every scrum ritual in the magically correct form where they actually provide value is forced upon the system by these levers. You can't possibly do it right-but-not-right-enough, you can only do it correctly or break the rules. The other effect of the workflow being performed continuously is that metrics can be gathered any time. There's no sprint-end-what-did-you-get-done-this-time team meeting, and there's no quarterly team leads sync where everyone presents a burndown chart that 0 people care about and a handful of people are converting into time estimates in their head. There's just, here's the graph that our software generates for us automatically, with its current values, and if you want to timebox it you can just pick a start and end date arbitrarily and look at it.
|
|
#
¿
Apr 7, 2023 19:37
|
|
|
12 rats tied together posted:Sure, but the problem is that everyone converts it to time based planning in their heads, because it's what actually matters. I forgot to mention that this type of kanban does not involve forecasting. Nobody in the Toyota warehouse is showing up to work every day and revealing a poker card that says they think attaching the door to the car is going to be 3 points. Because your WIP limit is 1, you don't need to cost anything, you just show up and do it. Your velocity is a measurement of the things you actually did, so it's 100% correct. The time it took you to attach the door to the car is tracked by your project management software as the time between the ticket entering "Doing" and the moving to "Done", so it's also 100% correct. The only time you might need more information than this is when your team lead is answering a question like "How long do you think it will take to complete this business initiative"? The good news is, this is time-based planning again, and all of the information your project management software generated for you about the things the team actually did and how long it actually took them is going to be way more useful than the fact that 12 rats tied together was bored at planning poker and just threw up "3 points" for everything so he could go back to his actual job. The other good news is that this is actually an important function of a tech team lead, so it can be part of their job description, which means they can be held accountable for their performance. They will also have a lot more time to develop the required expertise in estimation and tracking when they don't need to perform all the scrum rituals including the ones where everyone talks about which scrum rituals we should stop doing, which ones we aren't doing right, and which ones we were wrong to have stopped doing.
|
|
#
¿
Apr 7, 2023 19:55
|
|
|
of course it has no basis in reality but its absolutely important that we capture person X's performance in a graph so we can use it as an excuse to pip them later
|
|
#
¿
Jun 9, 2023 02:50
|
|
|
|
| # ¿ Apr 27, 2024 11:11 |
|
|
oop isn't inheritance though. you were always supposed to be not using inheritance simply as a way to share similar looking code. it's been like 2 decades since that was widely decried as a horrible idea.
|
|
#
¿
Jul 11, 2023 04:13
|
|