• 1 Post
  • 66 Comments
Joined 4 months ago
cake
Cake day: September 9th, 2025

help-circle
  • From a quick reading of the actual law, here are some of the AI uses it prohibits that will apparently “stifle innovation”:

    …use of an AI system that exploits any of the vulnerabilities of a natural person or a specific group of persons due to their age, disability or a specific social or economic situation

    …to assess or predict the risk of a natural person committing a criminal offence, based solely on the profiling of a natural person or on assessing their personality traits and characteristics

    …the use of an AI system that deploys subliminal techniques beyond a person’s consciousness or purposefully manipulative or deceptive techniques

    …the use of AI systems that create or expand facial recognition databases through the untargeted scraping of facial images from the internet or CCTV footage

    …the use of biometric categorisation systems that categorise individually natural persons based on their biometric data to deduce or infer their race, political opinions, trade union membership, religious or philosophical beliefs, sex life or sexual orientation









  • That’s fair, and having no consequences for unfinished work certainly takes the pressure off, though you’re correct that I’ve been on teams where there certainly were consequences for not getting done what you “committed to” for the sprint, which really made me resent the process. I’ve also been on teams where we happily moved unfinished work over each sprint, and it largely felt like we were just going through the motions. To your point, I suppose the latter is perfectly acceptable, though it felt wrong based on my previous experiences. In either case, I always wonder what the point is of time-boxing in the first place when you can just take it one backlog item at a time with Kanban while still engaging in the other useful practices.


  • At least in Star Trek, the robots would say things like, “I am not programmed to respond in that area.” LLMs will just make shit up, which should really be the highest priority issue to fix if people are going to be expected to use them.

    Using coding agents, it is profoundly annoying when they generate code against an imaginary API, only to tell me that I’m “absolutely right to question this” when I ask for a link to the docs. I also generally find AI search to be useless, even though DuckDuckGo as an example does link to sources, but said sources often have no trace of the information presented in the summary.

    Until LLMs can directly cite and include a link to a credible source for every piece of information they present, they’re just not reliable enough to depend on for anything important. Even with sources linked, it would also need to be able to rate and disclose the credibility of every source (e.g., is the study peer reviewed and reproduced, is the sample size adequate, etc.).




  • I started doing Scrum more than 15 years ago and I’ve worked on teams with full-time Scrum masters / project managers where the team genuinely did want to make the process work, but I have yet to be on a team where we did Scrum and figured out how to make it run like a well-oiled machine.

    I have indeed failed and learned from countless sprints over the years, and the main thing I’ve learned is that time-boxing doesn’t work. I have had success with Kanban / “Scrumban” that dispenses with the time-boxing, but does have planning, pointing, stand-up, retrospectives, backlog grooming, review and demo, etc.

    I guess I fundamentally reject the idea that a team should be able to plan and estimate weeks worth of work and if everything doesn’t go according to plan, then you did something wrong and need to figure out how to do better next time. Software development is design, which is always going involve a lot of exploration and learning, not manufacturing, so things not going according to plan is normal because if you’re doing it right, then you’re more knowledgeable today than when you made the plan weeks ago.

    With Kanban, if a 3-point story runs into unforeseen issues and you end up spending an extra day, no big deal. Maybe someone will even swarm on it with you. With Scrum, if that happens one or more times, you’re either putting in extra hours or not fulfilling your commitment for the sprint.

    The problem is that committing to a fixed scope in a fixed timeframe with a fixed team size is always bad idea, and Scrum makes an entire process out of this bad practice. It’s an improvement compared to full-on waterfall, but it’s still a flawed process, and getting rid of the time-boxing makes all the difference in my experience.





  • Where I find it useful instead is to push me past the initial block of starting something from scratch

    I think this is one of the highly understated benefits. I have to work in legacy codebases in programming languages I hate, and it used to be like pulling teeth to get myself motivated. I’d spend half the day procrastinating, and then finally write some code. Then I’d pull my hair out writing tests, only for CI to tell me I don’t have enough test coverage and there are 30 lint issues to fix. At that point, there would be yelling at the screen, followed by more procrastination.

    With AI, though, I just write a detailed prompt, go get some coffee, and come back to a pile of drivel that is probably like 70% of the way there. I look it over, suggest some refactoring, additional tests, etc., manually test it and have it fix any bugs. If CI reports any lint issues or test failures, I just copy and paste for AI to fix it.

    Yes, in an ideal world if I didn’t have ADHD and could just motivate myself to do whatever my company needs me to do and not procrastinate, I could write better quality code faster than AI. When I’m working on something I’m excited about, AI just gets in the way. The reality being what it is, though, AI is unequivocally a huge productivity boost for anything I’d rather not be working on.


  • melfie@lemy.loltoProgrammer Humor@programming.devScrum
    link
    fedilink
    arrow-up
    4
    ·
    edit-2
    4 days ago

    Scrum feels like a miniature waterfall. In the worst cases, a sprint is a race to make something that won’t be embarrassing at review and demo on Friday, and then you finish it over the weekend because it’s getting released Monday (with an incident in prod on Tuesday because you had to half-ass some things). Afterwards, the SM is nagging you to enter your actuals in JIRA “so we can track velocity”.

    Kanban is better in my experience since it at least does away with arbitrary deadlines, while still encouraging practices like backlog grooming and breaking down work into small units that can be completed in a week or less and then shipped. If you do a group pointing session and the consensus is that it’s going to take more than a few days, you go back and break it down further. If you run into issues with a work item and it takes a little longer than expected, no biggie, because quality is speed, unlike with Scrum where back-to-back sprints would force you to be working in the next thing because you’re now in a new sprint and last sprint’s work should’ve already been done. Didn’t you already show that in review and demo, so why are you still working on it?