101–110 of 452 posts
From a management perspective, having everything reduced to a process and method is the ideal world, as no true knowledge about the actual work is needed. The weaker then understanding of the work, the stronger the desire to replace uncertainty with process. However, no process can remove actual randomness (did anyone get the necessary ideas, for example) or uncertainty (is it even feasible, for instance). That said,…
Earlier quoted context omitted.
I worked on a Tensorflow feature in 2018. There was no branching involved. Fork the main repo, build the feature on your child repo, make sure all unit tests pass and then send a pull request to the main/master of the parent repo. Typically someone reviews the code, you incorporate code review comments, pass all unit tests, CI-CD pass, PR approved. That's it. Your code is in the next production cycle. So yes, you wor…
This is just branching, except your branch is in a different repo. You just call the branch downstream/master and your local master, instead of the more common origin/yourbranch and your local yourbranch. For the rest the merging issues are identical. You can still have a merge conflict between downstream/master and origin/master if someone merged something conflicting into origin/master since the fork happened.
Earlier quoted context omitted.
I've also seen some instance where gatekeeper were pretty effective at filtering users demands because some of those requests were too dumb and the "paying" users were used to have everything they wanted, and because they "paid" the dev department, "they had to do everything they wanted". Like asking for a 6months dev work to help them save 1 hour annually on an annoying task they had to do.
> Like asking for a 6months dev work to help them save 1 hour annually on an annoying task they had to do. I see this as a complaint a lot, but... in a private company, they're the ones writing the checks. So if they want to spend hundreds of thousands of dollars to save an hour, that's their prerogative. It's certainly our obligation to point out the cost (including ongoing maintenance) but again in a private compan…
I do however agree with leaving any organization that does not allow you to express disagreement.
The thing about Scrum is the observations and principles make sense, but then to sell it as a course they've turned it into very specific prescriptions. I went on a scrum course and the takeaway was basically that feedback is a big deal, and you should try to get some repeatedly and quickly. It's also common sense that you should have tasks written down somewhere, and that some of them are more important than others.…
I suspect the prescriptivism and detail have one end goal and that is for someone that has no idea how software is done to follow the procedures. It also turns the process into an "almost predictable process" for the higher-ups to see turned into a graph in some ppt. You also have to deal with people who needs to be told which shoe to put in first before they think the process is "confusing". Same reason for PMP, it'…
Perhaps it's just a difference in the scope and type of projects (boutique hardware vs. large scale online stuff).
Looking back at old codebases that I kept around, we managed to build quite complicated largish systems in a reasonable amount of time using straight waterfall/ad hoc approaches. Simple source control. Simple spreadsheets for bug lists.
Admittedly it's hard to avoid attaching particular people to particular blocks of a system, so perhaps making development capable of absorbing random Engineering Resource Units (humans) is the point of all this.
..or maybe it's just that earlier generations of programmers were stupid. I can accept that.
The thing about Scrum is the observations and principles make sense, but then to sell it as a course they've turned it into very specific prescriptions. I went on a scrum course and the takeaway was basically that feedback is a big deal, and you should try to get some repeatedly and quickly. It's also common sense that you should have tasks written down somewhere, and that some of them are more important than others.…
The problem with any system is that people try to enforce it, military style. In my previous job, we did scrum, but not too strict. We had two week cycles, not-too-strict deadlines (most of the time) etc. If I finished my task early, I was free to pick up tasks from the planned list, without having to get permission from my manager. We also didn't agonize over story points, retrospective etc. We did it light hearted…
I'm baffled by this behavior. If you know it is the next most important thing, why do you care? What would it change in your behavior if it is a 5 vs and 8? If you are looking at a task that you would choose not to do if it were an 8 but choose to do if it were a 5, then you probably look for something that is more important to work on.
I think you are right that much of that is driven by managers looking for metrics, but unless they understand what the metrics mean it is pointless.
The thing about Scrum is the observations and principles make sense, but then to sell it as a course they've turned it into very specific prescriptions. I went on a scrum course and the takeaway was basically that feedback is a big deal, and you should try to get some repeatedly and quickly. It's also common sense that you should have tasks written down somewhere, and that some of them are more important than others.…
Are Skype and Whatsapp even comparable? Whatsapp was competing with SMS (at least in developing countries) and it had a killer feature of making groups. Anyone who had a phone moved to WhatsApp overnight as they didn't wanted to pay for SMS.
Earlier quoted context omitted.
SAFe is beautiful in that it is the ultimate expression of Enterprise Agile Cargoculting: all pretenses of agility are lost, there are ten different levels of decision making, and all responsibility is diffused in a confused mess of worker bees running around under an all-powerful and all-seeing LPM > Individual teams can use whatever they want to manage themselves (Kanban, Lean, Scrum, etc…up to the team) Except tha…
You have PTSD from a bastardized version of SAFe, based on your description.
Earlier quoted context omitted.
> The first seems like it would be very frustrating if code with failing tests if pushed with any frequency, but seems to be literally what the phase "work on main" means. Yep, that's the point - it's to discourage devs from checking in failing code (because then they'll be swarmed by annoyed coworkers). It's fairly common to see developer A make a breaking change to some low-level library and then see developer B pu…
If that's fairly common it doesn't seem like a great setup? Why not automatically run the tests beforehand? And presumably there is no need for a staging env, since your code is deployed to production as soon as it has passed tests.
Edit: Just to clarify, it isn't ok to break downstream projects, if you do the change gets rolled back almost immediately. And you can run all tests for the change before submitting, but it isn't default since it is expensive for many core projects to run so many tests.